Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
On 02/26/14 15:53, Junio C Hamano wrote: > - start warning against "reset" (no mode specifier) and "reset --mixed" >when the index is unmerged *and* MERGE_HEAD exists; and then Why do we also want to check if index is unmerged? This situation can happen regardless of having conflicts or not (--no-commit, aborting the editor, etc.). As long as the user is in the middle of a merge (MERGE_HEAD exists), shouldn't they be warned if they used "git reset"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
On Wed, Feb 26, 2014 at 3:57 PM, Matthieu Moy wrote: > If you were to design "git reset"'s interface from scratch, your > proposal would make sense. But we're talking about a change, and you > can't expect that users never use the current behavior. At the very > least, there should be a warning telling the user that the behavior > changed, and I'm really afraid that the warning goes along the lines of > "I've thought you'd prefer me to discard your unsaved changes, please > rewrite them if you actually didn't want me to". > >>> 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", > > The point with backward compatibility is not to know whether users have > a good reason to, but whether you can guarantee that no one ever does > it. Yeah, I do see what you mean. But the problem of using "git reset --mixed" during a merge is problematic too. It leaves you with a mix of merge changes and local changes. As Junio pointed out, new files will also be left in the worktree. So users would have to clean all that up manually. Perhaps what Junio suggested is a better approach. Slowly phase out this behavior by printing out warnings. Then eventually erroring out in this situation, and then finally switch to a new behavior, whatever that may be. Andrew -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
Andrew Wong writes: > On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy > 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. But you can't repeat your merge conflicts resolution. > 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? I could. The point is, sometimes I don't. If you were to design "git reset"'s interface from scratch, your proposal would make sense. But we're talking about a change, and you can't expect that users never use the current behavior. At the very least, there should be a warning telling the user that the behavior changed, and I'm really afraid that the warning goes along the lines of "I've thought you'd prefer me to discard your unsaved changes, please rewrite them if you actually didn't want me to". >> 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", The point with backward compatibility is not to know whether users have a good reason to, but whether you can guarantee that no one ever does it. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
Matthieu Moy writes: > Andrew Wong 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. H, wouldn't it a better way to do this to run "git diff HEAD" without any resetting of the index, though? Having said that... > 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 ;-). ...this indeed may be a concern that deserves a bit more thought. > 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. If the only reason somebody might want to "reset --mixed" is to make the next "git diff" behave as if it were "git diff HEAD", I would be willing to say that we should: - start warning against "reset" (no mode specifier) and "reset --mixed" when the index is unmerged *and* MERGE_HEAD exists; and then - after a few releases start erroring out when such a "reset" is given; and then - use this patch to intelligently choose the default mode. Another downside of "reset --mixed" during a conflicted merge (or other mergy operations, e.g. "am -3") is that new files are left in the working tree, making the next attempt to redo the mergy operation immediately fail until you remove them, so in practice, the only mode I'd use with a conflicted index (be it from a conflicted merge or any other mergy operation) is "reset --hard". So forbidding "reset --mixed" when the index is unmerged (even when there is no MERGE_HEAD) may be a good idea in the long run. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
Andrew Wong 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] reset: Change the default behavior to use "--merge" during a merge
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.
Signed-off-by: Andrew Wong
---
builtin/reset.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 6004803..740263d 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -318,7 +318,12 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
_(reset_type_names[reset_type]));
}
if (reset_type == NONE)
- reset_type = MIXED; /* by default */
+ {
+ if(is_merge())
+ reset_type = MERGE;
+ else
+ reset_type = MIXED;
+ }
if (reset_type != SOFT && reset_type != MIXED)
setup_work_tree();
--
1.9.0.6.g16e5f9a
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
