cherry-pick generates bogus conflicts on removed files

cherry-pick generates bogus conflicts on removed files

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a commit I am trying to cherry pick that removes a number of
files.  It seems to generate conflicts for those files that have been
modified on this branch since the common ancestor.  Since they are
being removed, I don't care about what changes have been made on this
branch, just remove them.  Even git cherry-pick -Xtheirs does not
help.  How can I avoid these conflicts, or accept the deletions?  I
tried git add -u, but that seems to take my version rather than accept
the deletion, and there is no -u switch to git rm.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSYEFlAAoJEJrBOlT6nu75kSEIAMjqXl6nhfEhIMC66Zh4W/y0
MZ/+acDUNdvpCDtEpf9nPIFBQUKxdqAhUg0qYLSOvdvhQIvxkgo6nMo15MAA5Dd/
jNPZD78m0qwvNooUhFiHdqSEwob+2ntA9/VVP+LgCsRcK6BUqHs1Z3MKbe4vXPYr
+/bs11daxcnHH81aXOwRcOlUZRsG+yCDQiD9qjhPyv0BCCdS9splC+R7JZy4VaYb
6GQ03G7oY0yFGV9UAOXD1OqDwVPc30tinXlCM2GaBQNc11IQzpi813nEyxTOaf3Z
P5BXXH5ZzDNQS5F6Dn/VVNM6MMxVugIgGJafd4EkJiRHw4fIcUCX3/aeDoEDHlc=
=uy2D
-----END PGP SIGNATURE-----

Re: cherry-pick generates bogus conflicts on removed files

[Junio C Hamano]

Phillip Susi <psusi@ubuntu.com> writes:

> I have a commit I am trying to cherry pick that removes a number of
> files.  It seems to generate conflicts for those files that have been
> modified on this branch since the common ancestor.

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.

That does not need to mean that we should not make it easier for the
user to say "resolve these 'one side removed, the other side
changed' paths to removal".

"add -u" will be a way to say "Record the changes I made to my
working tree files to the index".  So presumably

	rm -f those files that the other branch removed
        git add -u

would be one way to do so.  Of course, you can also use "git rm"
directly, i.e.

	git rm -f those files that the other branch removed

Re: cherry-pick generates bogus conflicts on removed files

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> That does not need to mean that we should not make it easier for
> the user to say "resolve these 'one side removed, the other side 
> changed' paths to removal".
> 
> "add -u" will be a way to say "Record the changes I made to my 
> working tree files to the index".  So presumably
> 
> rm -f those files that the other branch removed git add -u
> 
> would be one way to do so.  Of course, you can also use "git rm" 
> directly, i.e.
> 
> git rm -f those files that the other branch removed

I have about two dozen such files.  Are you saying I have to
individually remove each one?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSYTbNAAoJEJrBOlT6nu752lAH/33YymYr773UZY8ryioA7dkQ
he3qjYzxWdIY2FtNFfYER1o1Q7PpeDLvq61b67IZ2htFjiK4+xgM/q+wjp3RMkXI
sA2vQ9iNn8dvR+PlzR9DgOFcDD17p3Q/xbu3H/M4Nt+H3px+Yz6sjUUSOzDAzXl8
ADQe0g4KkQnY4fjx+iWbrygY5xXCaQ52693pwYvR67GijfYxIuNb4d9DpkZhyqIZ
L6qjJH4FR1AZl6n5hPj0a9ZitrO8J/MjJ24oLVBfBU2h1GF5h7LoavkU02S874BZ
/8fULrCYfTCMSkyOCnk2xCkhw3sbqU9vEu90npI5X1nRbZZ0ro/DPAjXCgHB40c=
=EB2w
-----END PGP SIGNATURE-----

Re: cherry-pick generates bogus conflicts on removed files

[Junio C Hamano]

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.