I'm going to snip a lot here as I'm not really replying to one specific proposal or another. I just want to add some background: On Tue, Jun 23, 2020 at 2:48 PM Elijah Newren <newren@xxxxxxxxx> wrote: > Once you record the information for which files it applies to, then > you want it to happen whenever the merge machinery fires, right? This is, of course, already the case for merge drivers defined and used in .gitattributes entries (though note that they don't apply to some merge *strategies*, e.g., `-s ours` completely ignores them). > The problems I was raising were not with the resulting end-state tree > that users can construct or what happens with those trees once > constructed. My problems were with expected automatic behavior from > the merge machinery coupled with incomplete specifications that > sounded to me like a pile of corner cases and bugs that I'd have to > field while trying to maintain the merge machinery logic. This is already a bit of a problem with merge drivers in .gitattributes. In particular, suppose we're doing a standard merge of commits H (HEAD) and T (theirs) with respect to B (base). If the file is named "foo" and there is a merge driver defined for "foo", this merge driver is completely ignored *unless* all three copies of foo differ! And of course there are rename issues if a file's name was foo but isn't now or vice versa. I do think it might be reasonable to be able to mark a merge driver as "always use this, even if two or even all three inputs are the same". > Oh, and I have a problem with "branch specific" files from the email > you were responding to. I think those are a code smell. But my > primary concern was the expectations of some new automatic behavior > out of the merge machinery and how/if it gets configured. They're not only smelly :-) ... they don't even really mean anything. In particular, merge works not on *branches* but on *commits*. If we're merging commits H and T with base B, we may not be on any branch at all (detached HEAD) and there could be anywhere from zero to arbitrarily many branch names pointing at or containing each of the three commits. But of course it's common to have one branch name for each of H and T, and that's where most people who want this are coming from. In any case, the merge driver stuff is useful to some people sometimes. It might be a little more useful if you could force `git merge` to use it even if only "their side" of the merge has changed the file since the merge base. Chris
