On 23/06/2020 13:44, Sergey Organov wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> On 2020-06-20 at 18:21:40, Tiran Meltser wrote: >>> Hi, >>> This topic is quite common in various use cases (e.g. production >>> configuration vs. staging one) and there are quite a few talks about >>> it in the web. >>> Nevertheless, there is no specific solution to this problem, only >>> partial workarounds (including the famous merge driver “ours”). >> In general, this is a hard problem. When you perform a merge, you're >> asking to incorporate changes from both heads against a common merge >> base. What does it mean when you want to merge two branches together >> but not make any changes? Which version do you want, ours or theirs? > I believe we basically need support to apply different merge strategies > to different files. > > I had similar problem a few times when I merged a long-standing branch > and, after I saw the result of merge, I was basically satisfied, except > I needed to revert a few sub-directories of the project (that gave huge > number of conflicts), to their original state, either of my current > branch, or of the branch being merged, depending on particular case. You > see, I knew exactly what I needed, yet I was not able to achieve my goal > without resorting to nasty kludges. > >> Normally merges are symmetric, so if you want non-symmetric behavior, >> you have to define what it's supposed to be. > Yes, I'm ready to define what it's supposed to be. The problem is that > "git merge" won't let me, due to lack of support to apply different > merge strategies to different files. > > As I see it, first step of improvements could be to support > > git merge -- <files> > > where selected strategy applies only to <files>, and the rest of files > are kept intact (effectively applying "ours" strategy to them), So, essentially, for larger merges, this would be something like the recent `--pathspec-from-file=<file>` series https://public-inbox.org/git/7324e091ba7f48e286e6c35c7b7c40490e5c85d1.1576778515.git.gitgitgadget@xxxxxxxxx/ by Alexandr Miloslavskiy for the commands that did allow files to be passed in via `--` lists. It would still require merge to be extended to include just a 'partial-merge' or a 'file-merge' to clearly distinguish what is happening! This still a symmetric merge, but with _author supplied_ pathspec limiting, which is implicitly "ours" for the paths that are not merged. (I don't believe that the pathspec file can have negative pathspecs, so..) > along > with > > git merge --exclude=<files> > > , to be able to exclude specific files (apply "ours" only to them) > rather than include. One difficulty of .precious lists, whether embedded or local, is the false impression that they provide any form of security to the user, so it needs a name that make that clear. > > [ As a side-note, please notice that after such changes, the "ours" > strategy could be deprecated (not that I think it should), as either: > > git merge <branch> -- > > or > > git merge --exclude=. <branch> > > would do the trick. ] > > The next step would then be to support > > git merge --force -- <files> > > that would force to re-merge <files> with given strategy no matter what > their current status in the index is. Isn't this already the same as the restore/checkout? > > Even though such support would be enough for my specific use-case, it > doesn't provide suitable way to configure the default behavior. As a > more generic solution, a new syntax for "git merge" to specify what > merge strategy to apply to what files could be designed, and then > ability to put that syntax into a file for "git merge" to pick would > solve the problem of quasi-static configuration problem. Alternatively, > even more generic .gitignore way of doing things apparently could be > re-used to some degree by adding support for .gitmerge files. > > -- Sergey Philip
