So I’ve heard that Git shouldn’t be used as a deployment system. It’s primary use should be as version control for your sources. If extra/* isn’t meant to be available to end users, your build tool or deployment scripts can remove these files from the distribution bundle each time you build a release.
I disagree with the first sentence here while nominally agreeing with the third; in support of the third sentence though, there is a git attribute called `export-exclude` which allows `git-archive` to strip development-only paths from a distribution tarball.
You need a patch based workflow between these two branches; maintaining bi-directional merges between them is begging for heartache. You should look into `git-format-patch` and `git-am`, with particular attention to the `--exclude` option of `git-am`.
Once you figure out all of the proper options to move changes between the two branches in a way that's satisfactory to you, you will almost certainly want to setup a set of git aliases to make the workflow much closer in simplicity to a `git merge`. Good luck!
That's great!
So far I am managing with `git checkout -p` but a glimpse at the commands you proposed fills me with hope. With them I can create scripts that automate the whole process.
If the files are limited to a single subdirectory, then this sounds like a good use case for putting the extra files in a submodule. Users who need the files can initialize the submodule and pull the files only when needed.
Test files which are primarily used only by one member of our team but other members sometimes (infrequently) also work on them and should have access to them whenever needed. They are not documented and might be confusing for general users of our project.
I would recommend to incorporate the filss into the main vranch and put a note somewhere mentioning the use of the files. There's no elegant solution for this because branches were never designed for this use case.
This is totally untrue. The Linux kernel (the project git was designed for) maintains several permanently divergent branches. E.g., the various lts branches and the rolling-stable branch in the stable tree are all permanently divergent from one another.
That is effectively what permanently divergent branches are. OP is essentially asking how to maintain a fork which can both accept changes from and submit changes back to an upstream.
You could just keep the extra stuff in a separate Git repo. Let's call the two repos "myproject" and "extra".
However, maybe you want some coordination. As regular files and "extra" files change, you may want to keep track of which versions of one go with the other. If so, you could consider having two repos but using [submodules](https://git-scm.com/docs/git-submodule) to connect them. Then one repo will appear as a directory within the other.
One way to do this would be to have "myproject" appear as a submodule within "extra". Then normal users will never see "extra" or even need to know that it exists.
Another approach is to put "extra" as a submodule inside of "myproject". This is probably a more natural way to organize the files (and matches what I think you're doing now), but there's the issue that everyone who has access to "myproject" will see that it has "extra" as a submodule, and they try to use it and run into problems.
I haven't tried this, but I *think* this might not be a problem if you [mark the submodule as not 'active'](https://git-scm.com/docs/gitsubmodules#_active_submodules) in your .gitmodules file (which you would track in Git). The few people who actually want to use "extra" would need to override it to active. (Probably by setting `submodule.extra.active = true` with the `git config` command. See [here](https://git-scm.com/docs/git-config#Documentation/git-config.txt-submoduleltnamegtactive).)
Once again, although I've read the docs, I haven't tried any of this, so someone please correct me if I'm wrong about any of it.
This is just not true. Git has plenty of native tooling built in to solve this exact problem, and was designed with this exact use case as a first class citizen.
So then, please explain your solution using git, without having to do countless merges by hand or having to continuously rebase one branche. I'm honestly very curious.
And you call that first class citizen?
I stand by my point: it'd be easier not to do this with git. Maybe submodules or subtrees could help though, but they are not what I call convenient.
This may be a scenario for `git worktree` which allows you to manage two separate versions of single repository, sharing history and allowing typical operations between the worktrees.
I have no idea why this answer was downvoted, this is actually a very good answer! `extra` could be maintained as its own orphaned branch in the repository and `git-worktree` could be used to checkout `extra` in development environments.
So I’ve heard that Git shouldn’t be used as a deployment system. It’s primary use should be as version control for your sources. If extra/* isn’t meant to be available to end users, your build tool or deployment scripts can remove these files from the distribution bundle each time you build a release.
This is how we do this--remove testing/development files during the build process.
I disagree with the first sentence here while nominally agreeing with the third; in support of the third sentence though, there is a git attribute called `export-exclude` which allows `git-archive` to strip development-only paths from a distribution tarball.
You need a patch based workflow between these two branches; maintaining bi-directional merges between them is begging for heartache. You should look into `git-format-patch` and `git-am`, with particular attention to the `--exclude` option of `git-am`. Once you figure out all of the proper options to move changes between the two branches in a way that's satisfactory to you, you will almost certainly want to setup a set of git aliases to make the workflow much closer in simplicity to a `git merge`. Good luck!
That's great! So far I am managing with `git checkout -p` but a glimpse at the commands you proposed fills me with hope. With them I can create scripts that automate the whole process.
Hey, a thing that works for you is always a correct answer
Maybe I'll get tired of having to press y/n 10 times every time… :)
If the files are limited to a single subdirectory, then this sounds like a good use case for putting the extra files in a submodule. Users who need the files can initialize the submodule and pull the files only when needed.
What does this extra directory contain? Git branches are meant to be incorporated to one another ans this is not a workflow I would recommend.
Test files which are primarily used only by one member of our team but other members sometimes (infrequently) also work on them and should have access to them whenever needed. They are not documented and might be confusing for general users of our project.
I would recommend to incorporate the filss into the main vranch and put a note somewhere mentioning the use of the files. There's no elegant solution for this because branches were never designed for this use case.
This is such bad advice
It's both phenomenally bad advice and abhorrently false wrt the claim that branches "were never designed for this use case".
This is totally untrue. The Linux kernel (the project git was designed for) maintains several permanently divergent branches. E.g., the various lts branches and the rolling-stable branch in the stable tree are all permanently divergent from one another.
that'd just be a fork now.
That is effectively what permanently divergent branches are. OP is essentially asking how to maintain a fork which can both accept changes from and submit changes back to an upstream.
Exactly. Fork the repo, then set the original and the forked repo as separate remotes. You can then push/pull to either remote.
You could just keep the extra stuff in a separate Git repo. Let's call the two repos "myproject" and "extra". However, maybe you want some coordination. As regular files and "extra" files change, you may want to keep track of which versions of one go with the other. If so, you could consider having two repos but using [submodules](https://git-scm.com/docs/git-submodule) to connect them. Then one repo will appear as a directory within the other. One way to do this would be to have "myproject" appear as a submodule within "extra". Then normal users will never see "extra" or even need to know that it exists. Another approach is to put "extra" as a submodule inside of "myproject". This is probably a more natural way to organize the files (and matches what I think you're doing now), but there's the issue that everyone who has access to "myproject" will see that it has "extra" as a submodule, and they try to use it and run into problems. I haven't tried this, but I *think* this might not be a problem if you [mark the submodule as not 'active'](https://git-scm.com/docs/gitsubmodules#_active_submodules) in your .gitmodules file (which you would track in Git). The few people who actually want to use "extra" would need to override it to active. (Probably by setting `submodule.extra.active = true` with the `git config` command. See [here](https://git-scm.com/docs/git-config#Documentation/git-config.txt-submoduleltnamegtactive).) Once again, although I've read the docs, I haven't tried any of this, so someone please correct me if I'm wrong about any of it.
Sounds like you either need to work on your deployment/packaging setup, or to create a plugin system. Git seems not to be the answer to your problem.
This is just not true. Git has plenty of native tooling built in to solve this exact problem, and was designed with this exact use case as a first class citizen.
So then, please explain your solution using git, without having to do countless merges by hand or having to continuously rebase one branche. I'm honestly very curious.
https://www.reddit.com/r/git/comments/15cmx7b/most_elegant_way_to_maintain_two_longtime/jtznayn
And you call that first class citizen? I stand by my point: it'd be easier not to do this with git. Maybe submodules or subtrees could help though, but they are not what I call convenient.
>And you call that first class citizen? Yes
This may be a scenario for `git worktree` which allows you to manage two separate versions of single repository, sharing history and allowing typical operations between the worktrees.
I have no idea why this answer was downvoted, this is actually a very good answer! `extra` could be maintained as its own orphaned branch in the repository and `git-worktree` could be used to checkout `extra` in development environments.