Andrew Wong [off-list ref] writes:
If the user wants to do "git reset" during a merge, the user most likely
wants to do a "git reset --merge". This is especially true during a
merge conflict and the user had local changes, because "git reset" would
leave the merged changes mixed in with the local changes. This makes
"git reset" a little more user-friendly during a merge.
But this breaks backward compatibility.
I sometimes run "git reset" during a merge to only reset the index and
then examine the changes introduced by the merge. With your changes,
someone doing so would abort the merge and discard the merge resolution.
I very rarely do this, but even rarely, I wouldn't like Git to start
droping data silently for me ;-).
I'm not really convinced that this is such a good change, and if we go
this way, there should be a transition to let users stop using
argumentless "git reset" to reset the index during a merge.
The other 2 patches look good to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy
[off-list ref] wrote:
But this breaks backward compatibility.
I sometimes run "git reset" during a merge to only reset the index and
then examine the changes introduced by the merge. With your changes,
someone doing so would abort the merge and discard the merge resolution.
I very rarely do this, but even rarely, I wouldn't like Git to start
droping data silently for me ;-).
I don't think it's actually dropping data though, because your changes just
come from "git merge". So you can also do the merge again.
To examine the changes, you're saying you'd do "git reset && git diff". But
without doing "git reset", couldn't you do "git diff HEAD" to get the diff?
This also has the advantage of keeping git in the merging state, so you can
decide to continue/abort the merge later on.
I'm not really convinced that this is such a good change, and if we go
this way, there should be a transition to let users stop using
argumentless "git reset" to reset the index during a merge.
Yeah, this breaks compatibility, but like I said, during a merge, I don't
see a good reason to do "git reset --mixed", and not "git reset --merge".
Especially when there are local changes, "--mixed" would actually cause
more headaches than "git reset --merge", because you would lose the
distinction between merge changes and unstaged changes.
Andrew
Andrew Wong wrote:
Yeah, this breaks compatibility, but like I said, during a merge, I don't
see a good reason to do "git reset --mixed", and not "git reset --merge".
Yeah, in principle if it had a different behavior, then plain "git
reset" could be useful during a merge, but as is, I tend to use the
form with a path ("git reset -- .") to avoid losing MERGE_HEAD.
I really don't like the idea of making "git reset" modal, though. I'd
rather that reset --mixed print some advice about how to recover from
the mistake, which would also have the advantage of allowing scripts
that for whatever reason used "git reset" in this situation to
continue to work.
Thanks,
Jonathan
On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder [off-list ref] wrote:
I really don't like the idea of making "git reset" modal, though. I'd
rather that reset --mixed print some advice about how to recover from
the mistake, which would also have the advantage of allowing scripts
that for whatever reason used "git reset" in this situation to
continue to work.
In the case where user had unstaged changes before running "git
merge", there's no way to recover from the mistake. Their worktree is
left with a mix of both the merge changes and their original unstaged
changes. As Junio pointed out, new files will also be left in the
worktree, so the next attempt to "git merge" will fail until the files
are removed. There's no way to recover from it except to have the user
manually clean out the merge changes and new files manually. That's
why "git reset --mixed" doesn't seem sensible during a merge.
That said, I do feel it might not be a good idea to have the default
behavior of "git reset" change depending on the context. What Junio
suggested might be a better approach. To have "git reset" error out
instead may be a better alternative, since that doesn't silently do
something else and break compatibility.
Andrew