Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash

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.