Unstaging during a merge conflict

Unstaging during a merge conflict

[Matt McClellan]

We had an issue at our organization where changes were reverted when a
user was merging his local repo with the remote repo changes.  The
merge conflicted and he unstaged all the changes that were not a
conflict, he then resolved the conflict and added just the conflicted
file and committed.  The end result was that he reverted every change
from his last pull of the remote to his merge point.  The problem I'm
having how hard it is to see this problem as both git show and git log
on the merge commit do not show any reverted files.  It was found by
diffing his commit to each of the parents and seeing the opposite of
what we expected in the patch output.

Anybody have ideas how we can prevent these mistakes?  While we are
going to do more training, a hard stop that wouldn't even let these
make it to remote would be preferred.

I've done this using git add --interactive then reverting a files
changes, though the actual crime was done using egit staging tool.  It
seems the command line won't let you unstage changes but gui tools and
interactive tools seem to allow it.

Re: Unstaging during a merge conflict

[Junio C Hamano]

Matt McClellan <mcclellan.mj@gmail.com> writes:

> I've done this using git add --interactive then reverting a files
> changes, though the actual crime was done using egit staging tool.  It
> seems the command line won't let you unstage changes but gui tools and
> interactive tools seem to allow it.

I think you could do "git reset [--mixed]" from the command line to
induce the same mistake.  It may be that it is much less likely for
people to do this from the command line because the command name is
"reset" that is spelled in red ;-) than some GUI programs without a
careful UI to mark potentially dangerous operations as such, like we
do in the CLI.

Re: Unstaging during a merge conflict

[Jeff King]

On Mon, Oct 01, 2012 at 08:13:21PM -0500, Matt McClellan wrote:

> We had an issue at our organization where changes were reverted when a
> user was merging his local repo with the remote repo changes.  The
> merge conflicted and he unstaged all the changes that were not a
> conflict, he then resolved the conflict and added just the conflicted
> file and committed.  The end result was that he reverted every change
> from his last pull of the remote to his merge point.  The problem I'm
> having how hard it is to see this problem as both git show and git log
> on the merge commit do not show any reverted files.  It was found by
> diffing his commit to each of the parents and seeing the opposite of
> what we expected in the patch output.
> 
> Anybody have ideas how we can prevent these mistakes?  While we are
> going to do more training, a hard stop that wouldn't even let these
> make it to remote would be preferred.

The problem is that from the remote's perspective, it is too late. These
unstaged paths look exactly as if they were simply resolved in favor of
the "ours" side of the merge. The remote does not even see that they had
conflicts, but only that the path from one side was taken over the
other.  If it wanted to be careful, it could recreate the merge and
notice that they did not, but even that will lead to some errors. For
example, resolving another conflict may result in a situation where a
change in another file becomes unwanted and is dropped.

So I think any kind of receive hook to prevent these mistakes from being
propagated is going to run afoul of legitimate cases. You'd do much
better to work on the UI of the resolution workflow to prevent the
mistake from happening in the first place.

> I've done this using git add --interactive then reverting a files
> changes, though the actual crime was done using egit staging tool.  It
> seems the command line won't let you unstage changes but gui tools and
> interactive tools seem to allow it.

You can do "git checkout HEAD <path>" from the command-line. But I would
hope that the results of doing so are sufficiently obvious. Doing
something like "git reset" is much more subtle, but it is reasonably
well-known as a dangerous command, and I hope we are not encouraging it
to new people.

Doing a full revert of a path during merge resolution is probably fishy.
It might make sense for "git add -i" to warn about it (I haven't used
egit's staging tool, but presumably the same thing would apply).

Another place to catch your issue (assuming that an unstaging tool was
used, leaving the modified contents in the working tree) would be to
notice unstaged changes in the working tree when committing a merge.
The problem with forbidding it is that it is also a legitimate thing to
do (e.g., because you carry some local modification to a file that you
do not want to commit), so it is not necessarily indicative of an error.
But in theory you would see a giant list of unstaged changes in the
commit message template. I wonder if that is less obvious when
committing via egit.

-Peff