0

Is there a way to prevent git to merge files automatically as soon as both versions of a file differ from the common ancestor?

     changes foo.cpp
        |
    ----y---         (branch-a)
   / 
--x----------z---    (branch-b)
             |
         also changes foo.cpp

Let x be the common ancestor for the file foo.cpp.

In commit y e.g. a function bar() is removed from foo.cpp. Commit z adds a function bazz() at the end of foo.cpp.

When I merge branch-a into branch-b I want to be absolutely sure that function bar() is not present anymore after the merge. With the recursive merge strategy it sometimes happens, that bar() is present after the merge.

Are there any best practices in such situations?

schmitze333
  • 192
  • 1
  • 9
  • 1
    *"it sometimes happens, that bar() is present after the merge."* -- this sounds like an incorrectly solved conflict. – axiac Jan 23 '18 at 17:09
  • 1
    You need to provide concrete details of what you're seeing here, because your prose characterization of it does not match how Git behaves at all. – jthill Jan 23 '18 at 17:10
  • Sorry for bothering! After a lot of digging in revisions it turned out to be a wrong solved merge conflict indeed. – schmitze333 Jan 24 '18 at 08:38

1 Answers1

2

If you're seeing bar() not deleted, that must mean that git, for some reason, thinks that change has already been accounted for (and overridden) in the result. My guess would be that a merge was reverted, or a commit that's a common ancestor (before two branches diverged) was reverted on one of the branches, or something like that.

Point being, this is not normal behavior and it probably makes more sense to learn to recognize the situations where it could occur, than to thwart git's merge functionality altogether.

But, to answer your question, sure. You can use .gitattributes to specify a merge driver that always fails the merge. (A shortcut for that would be to mark the file as binary.) But doing that and getting any sort of useful "partially merged result" is considerably harder and requires custom coding beyond what I can usefully outline here.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52