Ramkumar Ramachandra <artag...@gmail.com> writes: > In the pull-merge case, maybe: if your worktree isn't clean, you lose > a lot of goodies like merge --abort anyway, and I hate that.
AFAICT, "git merge --abort" is an alias for "git reset --merge" 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. > Overall, I don't see how an extra stash/ stash pop where not > absolutely necessary hurts. It does. stashing means the user will have to "stash pop" later. One extra step, one extra opportunity to forget something important. 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. The fact that "git pull" just works on dirty trees with non-overlapping changes is an important feature of Git. >> Shouldn't this belong to "git merge" instead (i.e. implement "git merge >> --autosquash" and call it from "git pull")? Users doing "git fetch && >> git merge" by hand should be able to use --autosquash, I think. > > --autosquash reminds me of rebase.autosquash, and that is completely > unrelated to the issue at hand. A typo seems to have propagated in this thread. I meant auto*stash*, not auto*squash*, sorry. I guess it's the same typo in Junio's message. >> Something should be done for "git rebase" and "git pull --rebase" too. >> In this case, the UI can be much smoother, since the user would have to >> run "git rebase --continue" anyway, so you can do the auto-stash-pop for >> him by adding something like "exec git stash pop" at the end of the >> todo-list. > > No. I'm against executing a special codepath for a pull-rebase that > has no equivalent in the pull-merge world. 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. >> Ideally, "git rebase --abort" should auto-stash-pop too, although this >> is much less trivial to implement. > > As I already pointed out in my message to Junio, "fixing" rebase is > not the topic of discussion at all. It's not about fixing the existing rebase. It's about implementing autostash the right way. 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. -- 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
