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
> 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
> 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
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