On Sat, Nov 25, 2023 at 12:51:06AM +0100, Oliver Bandel wrote: > Quoting Michal Suchánek <msuchanek@xxxxxxx> (snt: 2023-11-24 21:59 +0100 CET) (rcv: 2023-11-24 21:59 +0100 CET): > > On Fri, Nov 24, 2023 at 05:39:12PM +0100, Oliver Bandel wrote: > > > Hello, > > > > > > I'm adressing the problem with files separated from the main branch(es), > > > which currently might be (more or less) solved with either submodules or subtrees. > > > I want to suggest a new command here. > > > > > > As usecase-example I assume a project that has 'branch_a' and 'branch_b' > > > with some files may be identical, some different between them. > > > I assume that the (classical) way the files are handled > > > by belonging to those branches is intended. > > > > > > Then say later I want to add more files to these branches, > > > but don't want to commit them in either of these existing branches. > > > Instead a branch 'branch_addons' is created, which solely contains > > > files that are used in 'branch_a' as well as 'branch_b'. > > > > Now you can merge branch_addons onto branch_a and branch_b and be done. > > Maybe my example or the explanation was not clear enough or stopped to early. > > After a merge, I may have added files from one branch to another branch > and some files might be changed during the merge operation and this is > persistent then. > > But the overlay would be a temporal situation and so no "pollution" with files from > other branches would occur and no changes of the files with same names > (some were just temporarily hidden). > > In an overlay situation, all involved branches are checked out into the > working dir (the non-hidden files are checked out) at the same time. > All changes (change/add/commit) could then be done in one go (with 'git > add' and 'git commit' as in the usual way), and all commits will only > affect those branches where the changed files are comming from. > This means editing more than one branch at the same time, > committing to more than one branch at the same time, > but not merging them. > > After un-overloading, the temporarily overlayed files from other > branches will be removed from the working dir by git. > No merge has been done, but changes to more than one branch might have > happened. > > I hope it's more clear now, how that differs from normal merge-branches situation. It's not clear why would anyone do that, though. > > Ciao, > Oliver > > P.S.: Changing sources and tests together but only publishing the code would be > easy this way. And why would you do that? Even if you wanted the git archive has option to exclude directories so you could publish separate releases from one branch. > Just check out the sources, overlay the tests, do the work, commit > the changes and after un-overlaying the sources branch has no > "tests pollution", and no other tricks are needed then. Since you detail how 'do the work' would commit the changes to both branches at the same time that means that specific revision of the code is tied to specific revision of the tests, different revisions would not work together. If the overlay branch is used with multiple different branches it will diverge, and will be compatible only with one of them at any time. Merging a specific revision of the overlay branch solves this problem. It ties the correct revision of the shared branch together with the correct revision of the separate files. It's the same with the interface-implementation example you gave earlier. > Also useful, when working with LaTeX documents and you temporarily > want to change the included extra files (or use the other layoutet > old version together with the current one) from a different > branch, but don't want the changes be permanently in your > currently preferred main branch (nevertheless change the main-doc > and the extra files in one go). Don't really understand what you are trying to do here. > For those people who commit their passwords or private keys into git, > this also could increase security ;-) > For testing the code, the secrets are just overlayed. Or not put those into project git in the first place. When the secrets are in an 'overlay branch' in the same repository they are published anyway. Thanks Michal
