Re: cherry-pick generates bogus conflicts on removed files

[Junio C Hamano <gitster@pobox.com>]

Phillip Susi <psusi@ubuntu.com> writes:

> 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.