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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 15, 2013, 13:15 UTC
Message-ID: <CALkWK0mdC_tK2CGqAa67fr189PQCjSjzAOPujipOHFfoiYW0qA@mail.gmail.com>
In-Reply-To: <vpq38us2oov.fsf@grenoble-inp.fr>

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.