Re: [RFC 0/3] Make git more user-friendly during a merge conflict
David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: do the right thing commands also tend to do the wrong thing occasionally with potentially disastrous results when they are used in scripts where the followup actions rely on the actual result. That is bad, and should not be allowed. On the other hand, I have yet to see an actual use case of bad behavior in this discussion. Huh. http://permalink.gmane.org/gmane.comp.version-control.git/242744 That's about backward incompatibility, which is bad, but not what I was talking about above. No, it isn't. I quote: 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 ;-). You should not make statements like I have yet to see an actual use case of bad behavior in this discussion when you actually mean I have not yet seen anything I would be interested in doing myself. Clearly I misunderstood your point. Merely repeating the same statement that I misunderstood, and adding a misunderstanding of what I said, is not helpful. So let me see if I can expand on your use case: - you do 'git merge', which results in conflicts - you edit some workspace files to resolve some of those conflicts (I added this step later, since it was implied but not explicit) - you do 'git reset', intending 'git reset --mixed' (because that is the current default) Actually, I can't find a precise definition of 'git reset'. Here is the synopsis from the man page for 'git-reset' (from git 1.7.9): git reset [-q] [commit] [--] paths... git reset (--patch | -p) [commit] [--] [paths...] git reset (--soft | --mixed | --hard | --merge | --keep) [-q] [commit] In 'git reset', there is no path, so it must be the second or third form. But those _require_ one of the -- options. So 'git reset' is illegal. Clearly something is wrong here; apparently the third line should be: git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [commit] with '--mixed' as the default, as is stated later. (perhaps the original intent was to not have a default for the third form, but that got changed sometime?). This command resets the index but not the working tree. I'm not clear what reset the index means here; does it mean remove all entries from the index, or reset the index to some previous state? In other man pages, reset can have either meaning depending on context. - then you examine changes introduced by the merge. I don't know what this means in detail. Before resetting the index, you could diff a workspace file against either HEAD or index. Now you can only diff against HEAD, so I don't understand why you wanted to reset the index. That's not relevant to this use case; I'll just accept that resetting the index is a useful thing to do here. But I would like to understand why. - with the do the right thing patch, 'git reset' does 'git reset --merge' instead That Resets the index and updates the files in the working tree that are different between commit and HEAD. commit in this case defaults to HEAD, so the working tree is not changed. So as I understand it, this does _not_ lose your conflict resolutions. In fact, it now seems that 'git reset --mixed' is always the same as 'git reset --merge'. So I must be missing something! -- -- Stephe -- 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 0/3] Make git more user-friendly during a merge conflict
Stephen Leake stephen_le...@stephe-leake.org writes: So as I understand it, this does _not_ lose your conflict resolutions. Well, then maybe it's time to try the command before continuing commenting on its behavior ;-). $ git status [...] both modified: foo.txt [...] $ git diff diff --cc foo.txt index 595f399,996c0e1..000 --- a/foo.txt +++ b/foo.txt @@@ -1,1 -1,1 +1,1 @@@ - content1 -content2 ++resolved $ git reset --merge $ git status On branch master nothing to commit, working directory clean $ In fact, it now seems that 'git reset --mixed' is always the same as 'git reset --merge'. So I must be missing something! git reset --merge is an alias for git merge --abort (IIRC, it's actually the other way around). Essentially, it reverts, or tries to revert everything (worktree and index) as it was before the merge. That includes throwing away conflict resolution. Now, I do agree that the documentation of git reset is terrible, and I actually think that the command does too many different things (putting git reset and git reset --hard so close to each other is not a good idead IMHO: the first is a harmless command I use very often, and the second is one of the most destructive operation Git has). -- 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 0/3] Make git more user-friendly during a merge conflict
Matthieu Moy matthieu@grenoble-inp.fr writes: $ git status On branch master nothing to commit, working directory clean $ ok, you've lost your conflict resolutions. In fact, it now seems that 'git reset --mixed' is always the same as 'git reset --merge'. So I must be missing something! git reset --merge is an alias for git merge --abort (IIRC, it's actually the other way around). Essentially, it reverts, or tries to revert everything (worktree and index) as it was before the merge. That includes throwing away conflict resolution. Ok. Now, I do agree that the documentation of git reset is terrible, Ok, good. So is this a sufficient bug report to request that the documentation be fixed? (I obviously don't know enough to even think about submitting a patch). -- -- Stephe -- 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 0/3] Make git more user-friendly during a merge conflict
Jonathan Nieder jrnie...@gmail.com writes: Hi, Andrew Wong wrote: The first two patches are just about rewording a message, and adding messages to tell users to use git merge --abort to abort a merge. Sounds like a good idea. I look forward to reading the patches. We could stop here and hope that the users would read the messages, but I think git could be a bit more user-friendly. The last patch might be a bit more controversial. It changes the default behavior of git reset to default to git reset --merge during a merge conflict. I imagine that's what the user would want most of the time, and not git reset --mixed. I don't think that's a good idea. I'm not sure what new users would expect; As a newbie, I would like to know how to abort the merge, so I like this message. in any case, making the command context-dependent just makes the learning process harder imho. I like commands that do the right thing. So no, this would not be confusing. And for experienced users, this would be a bad regression. Backward incompatibility is a real concern. It might be best if git reset (with _no_ option) be made to error out, so all users have to specify what they want. The transition process Junio proposed sounds good to me. -- -- Stephe -- 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 0/3] Make git more user-friendly during a merge conflict
On Fri, Feb 28, 2014 at 03:01:53AM -0600, Stephen Leake wrote: Jonathan Nieder jrnie...@gmail.com writes: And for experienced users, this would be a bad regression. Backward incompatibility is a real concern. It might be best if git reset (with _no_ option) be made to error out, so all users have to specify what they want. This is just as much of a regression (if less dangerous) as changing the default behaviour of git reset to touch the working tree. 'git reset' is a very, very common action for me and simply means 'reset [my index] [to HEAD]'. I frequently find myself resetting so that I can stage something a bit different to what I had originally intended. -- 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 0/3] Make git more user-friendly during a merge conflict
Stephen Leake stephen_le...@stephe-leake.org writes: I like commands that do the right thing. So no, this would not be confusing. I _hate_ commands that think they know better than to do what they are told. In particular when doing destructive things. And just because _you_ like them does not mean they are not confusing. In the long run, it is much more confusing if you come to rely on some commands doing the right thing while in other cases, the actually written thing is done. do the right thing commands also tend to do the wrong thing occasionally with potentially disastrous results when they are used in scripts where the followup actions rely on the actual result. -- David Kastrup -- 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 0/3] Make git more user-friendly during a merge conflict
David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: I like commands that do the right thing. So no, this would not be confusing. I _hate_ commands that think they know better than to do what they are told. In particular when doing destructive things. And just because _you_ like them does not mean they are not confusing. Ok, I should have said not confusing for me. People differ. In the long run, it is much more confusing if you come to rely on some commands doing the right thing while in other cases, the actually written thing is done. There should always be the option of telling git exactly what to do. In my emacs front end, the command that does the right thing is _called_ do-the-right-thing. All of the other commands do exactly as told. In this case, it is only git reset that would do the right thing, since you did _not_ tell it specifically what to do. Relying on a default is always problematic, in my experience; I much prefer no default to a default that people voted on 10 years ago, and now we are stuck with it. do the right thing commands also tend to do the wrong thing occasionally with potentially disastrous results when they are used in scripts where the followup actions rely on the actual result. That is bad, and should not be allowed. On the other hand, I have yet to see an actual use case of bad behavior in this discussion. -- -- Stephe -- 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 0/3] Make git more user-friendly during a merge conflict
Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: do the right thing commands also tend to do the wrong thing occasionally with potentially disastrous results when they are used in scripts where the followup actions rely on the actual result. That is bad, and should not be allowed. On the other hand, I have yet to see an actual use case of bad behavior in this discussion. Huh. http://permalink.gmane.org/gmane.comp.version-control.git/242744 -- David Kastrup -- 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 0/3] Make git more user-friendly during a merge conflict
David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: do the right thing commands also tend to do the wrong thing occasionally with potentially disastrous results when they are used in scripts where the followup actions rely on the actual result. That is bad, and should not be allowed. On the other hand, I have yet to see an actual use case of bad behavior in this discussion. Huh. http://permalink.gmane.org/gmane.comp.version-control.git/242744 That's about backward incompatibility, which is bad, but not what I was talking about above. Specifically, the proposed change is: 'git reset' will have different default actions depending on context: - if a merge is not in progress, it will do 'git reset --mixed' - if a merge is in progress, it will do 'git reset --merge' Is there a use case where this will do the wrong thing? Of course, I fully understand that not being able to come up with a wrong thing use case is not the same as proving it cannot happen, especially for a system as complex as git. So it would be ok to say we don't do that so we are not exposed to unintended consequences. But wrong thing use cases are more convincing :). -- -- Stephe -- 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 0/3] Make git more user-friendly during a merge conflict
Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: do the right thing commands also tend to do the wrong thing occasionally with potentially disastrous results when they are used in scripts where the followup actions rely on the actual result. That is bad, and should not be allowed. On the other hand, I have yet to see an actual use case of bad behavior in this discussion. Huh. http://permalink.gmane.org/gmane.comp.version-control.git/242744 That's about backward incompatibility, which is bad, but not what I was talking about above. No, it isn't. I quote: 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 ;-). You should not make statements like I have yet to see an actual use case of bad behavior in this discussion when you actually mean I have not yet seen anything I would be interested in doing myself. -- David Kastrup -- 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 0/3] Make git more user-friendly during a merge conflict
Users may not be aware that they need to use git merge --abort or git reset --merge to properly abort a merge conflict. They are likely to just use git reset, because that usually cleans up the repo. But in the case where the user had local changes, git reset would leave the repo in a messy state where merged changes and local changes are mixed together. The first two patches are just about rewording a message, and adding messages to tell users to use git merge --abort to abort a merge. We could stop here and hope that the users would read the messages, but I think git could be a bit more user-friendly. The last patch might be a bit more controversial. It changes the default behavior of git reset to default to git reset --merge during a merge conflict. I imagine that's what the user would want most of the time, and not git reset --mixed. I haven't updated the git reset docs yet, I'll update it if we decide to use this new behavior. Comments? Andrew Wong (3): wt-status: Make conflict hint message more consistent with other hints merge: Add hints to tell users about git merge --abort reset: Change the default behavior to use --merge during a merge builtin/merge.c | 3 ++- builtin/reset.c | 7 ++- wt-status.c | 5 - 3 files changed, 12 insertions(+), 3 deletions(-) -- 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
Re: [RFC 0/3] Make git more user-friendly during a merge conflict
Hi, Andrew Wong wrote: The first two patches are just about rewording a message, and adding messages to tell users to use git merge --abort to abort a merge. Sounds like a good idea. I look forward to reading the patches. We could stop here and hope that the users would read the messages, but I think git could be a bit more user-friendly. The last patch might be a bit more controversial. It changes the default behavior of git reset to default to git reset --merge during a merge conflict. I imagine that's what the user would want most of the time, and not git reset --mixed. I don't think that's a good idea. I'm not sure what new users would expect; in any case, making the command context-dependent just makes the learning process harder imho. And for experienced users, this would be a bad regression. An 'advice' message pointing the user to 'git merge --abort' might make sense, though. What do you think? 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
