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? > 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. - You're doing a pull-rebase. In the case when there are no conflicts, what is the problem? > 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? I _never_ run merge on a dirty worktree myself. > The fact that "git pull" just works on dirty trees with non-overlapping > changes is an important feature of Git. 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). > I think you're taking it the wrong way. You seem to insist that > autostash should be a pull feature. I think it should be a feature of > merge and rebase, and the convenience script "git pull" should expose > them to the user. > > I see no reason to prevent users running fetch and then merge or rebase > to use the autostash feature. Okay, so you're proposing a uniform --autostash feature for both merge and rebase. Sorry, I didn't get it last time due to the typos in your email; yeah, this is worth investigating. > 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? -- 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