Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Matthieu Moy wrote: >> AFAICT, "git merge --abort" is an alias for "git reset --merge" > > Yes, that is correct. > >> which >> was precisely designed to reset only modifications comming from a merge, >> and not the local changes that were present before the merge was >> started. The man pages are relatively obscure on the subject, but I'd >> call that a documentation bug. > > I see. Either way, we need a clean worktree for it to work, no? No, you don't. Just try if you're not convinced: $ git checkout -b branch Switched to a new branch 'branch' $ date > test.txt && git commit -m 'on branch' test.txt [branch 2482623] on branch 1 file changed, 1 insertion(+), 1 deletion(-) $ git checkout - Switched to branch 'master' $ date > test.txt && git commit -m 'on master' test.txt [master c322d35] on master 1 file changed, 1 insertion(+), 1 deletion(-) $ date > other.txt $ git status # On branch master # Changes not staged for commit: # # modified: other.txt # no changes added to commit (use "git add" and/or "git commit -a") $ git merge branch Auto-merging test.txt CONFLICT (content): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result. $ git status # On branch master # You have unmerged paths. # # Unmerged paths: # # both modified: test.txt # # Changes not staged for commit: # # modified: other.txt # no changes added to commit (use "git add" and/or "git commit -a") $ git merge --abort $ git status # On branch master # Changes not staged for commit: # # modified: other.txt # no changes added to commit (use "git add" and/or "git commit -a") $ There may be corner-cases where it doesn't work, but I never encountered such case. >> It does. stashing means the user will have to "stash pop" later. One >> extra step, one extra opportunity to forget something important. > > That's only if there are conflicts. If there are conflicts, you'll > have to stash anyway if: > - You're doing a pull-merge and want merge --abort to work. Again, no. >> A minor annoyance is that it will touch files that have no reason to be >> touched, hence may trigger extra rebuilds with "make", disturbing text >> editors that have the file open, etc. > > Okay, I need to ask you something at this point: do you ever run merge > on a dirty worktree unless you're absolutely sure that your local > changes won't conflict with the changes introduced by the merge? Most of the time, I just run "git pull" or "git merge". I know it's conservative enough, to it will stop if there's anything dangerous. > That's only a pull-merge. Unfortunately, making git-pull.sh uniform > means that we have to fall back to the least-common-denominator of > functionality (which is currently pull-rebase). You may want to, but you don't have to. pull-merge and pull-rebase already have different behavior in case of non-overlapping changes: $ git pull --rebase . branch Cannot pull with rebase: You have unstaged changes. Please commit or stash them. $ git pull --no-rebase . branch >From . * branch branch -> FETCH_HEAD [...] I don't see any reason to restrict to the common denominator in the same situation for another feature. I can accept the "it's too hard to implement" argument, but not "it doesn't bring anything". >> As a user, when I run "git rebase --continue" and it tells me it's done, >> I expect the work to actually be done. This is the case today. This >> won't be the case after autostash is introduced if the user has to >> remember to run "stash pop" afterwards. > > And how will you implement that for merge, since there is no merge > --continue to execute stash pop from? Do you propose to make commit > do the stash pop'ing? No, I'm not proposing to do anything for merge. There's no reason to try being uniform in conflict resolution for pull-merge and pull-rebase as it is already different now. We already have "git rebase --continue", we don't have "git merge --continue". So what? The fact that merge doesn't have the equivalent doesn't mean we should not do something for "rebase --continue". -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html