Junio C Hamano <gitster@xxxxxxxxx> writes:
> During a conflicted merge when you have unmerged stages for a path F in
> the index, if you asked:
>
> $ git checkout F
>
> we rewrote F as many times as we have stages for it, and the last one
> (typically "theirs") was left in the work tree, without resolving the
> conflict.
>
> This patch fixes it by noticing that a specified pathspec pattern matches
> an unmerged path, and by erroring out.
The patch claims that it is a bugfix, but I have a slight worry that
somebody might be depending on this broken behaviour in their workflow.
$ git pull
Conflicts in foo.c (modify/modify)
.. Eeek, conflicts. My changes are always crap, and I trust my
.. upstream more than I trust myself, so I'll take advantage of
.. the bug to check out "their" version.
$ git checkout foo.c
In modify/modify case, because we will have stage #3 (state after their
change), that will be the version you will get as the final result of this
broken behaviour of "checkout".
This patch alone will make the above to check out "theirs" an error. In a
later one in the series, you can still say:
$ git checkout --theirs foo.c ;# or "git checkout -3 foo.c"
to get the feature back, at the same time you will now be able to say
$ git checkout --ours foo.c ;# or "git checkout -2 foo.c"
for symmetry (admittably, it is the same thing as "git checkout HEAD
foo.c").
So we _could_ choose to stay backward compatible by leaving this "bug"
unattended without loss of ability to checkout either theirs or ours, even
though without fixing this, you cannot sanely add "git checkout -m foo.c"
feature that comes later in the updated series, which allows you to go
back to the original conflicted state after you (or rerere) messed up the
working tree state.
Thoughts?
--
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
