4

There is a project using github repositories. When there are conflicts to be resoled before merging pull request some 90% of conflict cases concern just one CHANGELOG file containing list of completed tickets, sth like:

## current

<<<<<<< HEAD
ISSUE-128 done some 128
ISSUE-131 done some 131
=======
ISSUE-125 done some 125
>>>>>>> ISSUE-125
ISSUE-126 done some 126
ISSUE-120 done some 126
ISSUE-123 done some 126

I wonder if there is a way to automate merge of this particular file (possibly by providing some configuration using i.e. gitignore format) with a simple rule to just accept the changes from both sides (as for the order its enough that the changes will be just next to each other, knowing how could be possible to control the order is secondary yet interesting). Additional rule could be to verify if there is always just one addition on each side and only then proceed with the automatic merge.

Ideally would be to have such configuration on github yet even local git solution would be helpful.

ciekawy
  • 2,238
  • 22
  • 35
  • What you want here is usually called *union merge* and this is actually built in to Git. It rarely does the right thing, but for this particular case, union merge is actually *probably* correct. See http://stackoverflow.com/q/13263902/1256452 – torek Jul 21 '16 at 11:32
  • looks like this is exactly what I need, including possibility to configure file set. I'd be happy to accept the answer if you write one :) – ciekawy Jul 21 '16 at 11:41
  • Actually the only thing I'm still somehow worry about is that for a "more complex" conflicts I'd rather see that there is conflict to merge – ciekawy Jul 21 '16 at 11:44

2 Answers2

2

[Answer, slightly modified from comments.]

What you want here is usually called union merge, and this is actually built in to Git. It rarely does the right thing, but for this particular case, union merge is actually probably correct. You can set union merge for a particular file name using .gitattributes. See git merge, keep both for more about this.

Actually the only thing I'm still somehow worry about is that for a "more complex" conflicts I'd rather see that there is conflict to merge

Right: the main problem with union merge, I think, is that it always succeeds, even if the merge result is nonsensical. You need to remember that it is set up this way, and be careful to check the merge result every time.

(Personally I'd be happier with all of this if Git had it split out into a separate "resolve" command one could invoke on each file. I think the git merge-file command is, in fact, mostly what one wants here, except that it is a pain to use. With a more useable interface, instead of -X ours and -s ours and -X theirs and so on, and various merge drivers in .gitattributes, we could just let the merge conflicts happen, inspect them, decide which side(s) to keep if that suffices, and go with that. Of course if one goes much further down this road, one ends up with a GUI merge tool...)

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • with all the information you've made me wonder if it would be possible to define custom merge driver which will work on a github in the way that for any more complex cases will just fail and so github will show a message that there are conflicts to be resolved and for the "simple case" there will be just green button allowing to preform the merge. I'll probably will try to prepare such `.gitattributes` config... – ciekawy Jul 21 '16 at 12:37
  • From what I see, Union does "keep both minus intersection". So if the changes in both branches/files contain a few lines that are the same, they may not be duplicated in the result. Because git will consider them non-conflicting. This is not what we want. We want all changes from both branches to be merged, and possibly duplicated. Did I get that right? – Stan Mar 22 '22 at 16:32
  • 1
    @Stan: that might indeed be what you want, and yes, that's not what union merge does (since it only union-izes *conflicts*). You'd have to write your own custom merge. – torek Mar 23 '22 at 11:06
0

That problem occurs frequently; aside from Changelog style files, it also happens if you have, for example, source files and add new stuff - most times you add new methods or whatever at some canonical place (like near the end of the file), and upon merge they all show up as conflict, every time.

Short answer: git cannot help you here, nor can any other automatic merge tool, short of true artifical intelligence. There is the union driver mentioned elsewhere, but, quite frankly, this would be much to dangerous for me, even for a Changelog file. You could do it with a custom merge driver which understands your Changelog format, but the effort will likely put you off of that idea (if so, the gitattributes manpage has more information for you).

Side answer / tip: I had some success with having comments like this in my source files:

  def lastmethodinclass
    ...
  end

  ## placeholder 1 ##

  ## placeholder 2 ##

  ## placeholder 3 ##

end # class

Then, in a first branch, I put a new method behind "placeholder 1". If I later remember, in another branch, that I have "used up" the first placeholder, I put my next method after the second placeholder, and so forth.

This is still very awkward, but it works to avoid those pesky conflicts. From time to time, I clean out old placeholders that accumulate after merges and stuff them back where they belong.

Useless when coding with others, yup.

AnoE
  • 8,048
  • 1
  • 21
  • 36