Re: cherry-pick generates bogus conflicts on removed files

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 22, 2013, 17:01 UTC
Message-ID: <xmqq7gd5utn0.fsf@gitster.dls.corp.google.com>
In-Reply-To: <526136CD.6080903@ubuntu.com>

Phillip Susi <psusi@ubuntu.com> writes:

Show 10 quoted lines

> On 10/17/2013 5:14 PM, Junio C Hamano wrote:
>> Correct.
>> 
>> Without inspecting them, you would not know what you would be
>> losing by blindly resolving to removal, hence we do not
>> auto-resolve "one side removed, the other side changed" to a
>> removal.
>
> Even when I specify the "theirs" strategy?  It seems like saying to
> unconditionally accept their changes should not generate conflicts.

I think you are thinking about "-Xtheirs" (which is not a strategy).

There is no "theirs" strategy, IIRC, even though there is "ours" strategy (the asymmetry is pretty much deliberate), but if there were, it would tell Git to unconditionally accept their version, just like "ours" strategy does for our version.

Just in case you are unfamiliar with how the merge works, during a merge, these things happen:

 - we first merge at the tree structure level; trivial cases such as
   "one side changed, the other side kept the original" and "one
   side changed, the other side also changed but to the identical
   result" will be resolved during this phase.

 - paths that changed by one side in one way and by the other side
   in a different way are fed to the content-level merging code to
   decide the merged contents for each path.  -X<options> are given
   to this content-level merge logic.

 - other paths that do not qualify for content-level merging
   (i.e. lacking the two resulting versions) are left conflicted.

If you do not have it in "ours" side, the content-level three-way merge mechanism does not even kick in in the current code.

It might be a good idea to peek into -Xtheirs/-Xours during the tree-level merging phase and have these options help resolve the structure level merges, but I think it needs to be thought through to avoid surprises. While I tend to agree with you that when you are using "-Xtheirs" to really prefer all their changes over your changes when they overlap at the content level, you are likely to prefer ignoring your changes and take their removal of a path, I suspect that there may be those who want the preference applied only to the whole-file "I changed the path that they have already removed" without losing the ability to inspect the content level conflicts in files that both sides kept and resolve them manually, instead of blindly taking theirs, for example, and if that is the case, overloading this new behaviour about the whole-file removal to existing "-Xtheirs" may be a mistake.