Matthieu Moy wrote: > Isn't this too pessimistic? If the local changes do not overlap (in > terms of files) with the pulled changes, then autosquash is not needed. > > There should be a test for the case of non-overlapping changes. In the pull-rebase case, no; it is not too pessimistic. 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. Secondly, it's impossible to determine whether the changes overlap or not before actually running merge_trees(). If there were an easy way to do it, I might have considered it. Overall, I don't see how an extra stash/ stash pop where not absolutely necessary hurts. > 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. Did you mean git merge --squash (to update the worktree/index but not create the actual commit?). Sure, it's probably useful to have a merge.squash configuration variable, but I don't see what it has to do with the pull.autostash I'm proposing. > 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. Or did you mean: have one configuration variable to git merge --squash and do this for git rebase, as if they're equivalent from the pull perspective? No, they aren't. > 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. > Maybe a good first step is to implement --autosquash only for non-rebase > pull, and later to implement "git rebase --autosquash" and call it from > "git pull". "Implement" git rebase --autosquash? If I just set rebase.autosquash to true, the rebase will automatically autosquash whether called from git pull or otherwise. Sorry, I just don't understand what you're saying. -- 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