On Mon, Nov 17, 2014 at 01:39:43PM -0500, Daniel Hagerty wrote:
> "git merge b" produces a successful merge, as both branches perform
> the "same" work.
Just to be clear, you were expecting "git merge b" to produce a
conflict?
> For the body of content in question, this is a merge conflict. Git
> seems to have the hard-coded assumption otherwise. I had to change
> three source files to get the result I expected, and wasn't seeing
> any indications of parameterization.
I can imagine there might be times you would like to notice this case
and visit it manually (e.g., even though the conflict would show both
sides with the same content, you might want the resolution to take the
two sides sequentially, duplicating them). But there are also cases
where choosing the new content is helpful (e.g., one side cherry-picks a
commit from the other, then later merges; you would not want to see a
conflict there).
> Am I missing some means of getting the results I need? Thanks!
I don't think there is an easy way to get what you want. You would have
to write a new merge 3-way strategy that handles this case differently.
And most of the file-level heavy lifting in merge strategies is done by
the low-level unpack_trees code, which handles this case. From "git help
read-tree", which describes the index-level 3-way merge:
· stage 2 and 3 are the same; take one or the other (it makes no
difference - the same work has been done on our branch in stage 2
and their branch in stage 3)
So I think you would have to add an option to git to handle this, unless
you want to reimplement quite a lot of code in your merge strategy.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html