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
Andrew Wong andrew.k...@gmail.com 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
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 matthieu@grenoble-inp.fr 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 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
Matthieu Moy matthieu@grenoble-inp.fr writes: Andrew Wong andrew.k...@gmail.com 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 andrew.k...@gmail.com writes: On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy matthieu@grenoble-inp.fr 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
On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder jrnie...@gmail.com 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
On Wed, Feb 26, 2014 at 3:57 PM, Matthieu Moy matthieu@grenoble-inp.fr 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
