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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2013, 09:52 UTC
Message-ID: <7vbo9g15po.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpq38us2oov.fsf@grenoble-inp.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 9 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> +stash_required () {
>> +	! (git diff-files --quiet --ignore-submodules &&
>> +	git diff-index --quiet --cached HEAD --ignore-submodules)
>> +}
>
> 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.

Yes, that is why I said for pull-merge, --authsquash is neutral-to-better and pull.autosquash is harmful.

But for pull-rebase folks, I can understand why this "working tree must be squeakily clean" logic is appropriate, if we were to do this. The root cause is because rebase insists to be run on such a working tree.

And the worst part is that in order to check if local changes overlap, you need to fetch first. But Ram's annoyance is about the user being told the merge/rebase cannot proceed _after_ fetch is done.

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

See my other message. I do not think autosquash would help "merge" folks very much, and will actively hurt when it matters.

> Something should be done for "git rebase" and "git pull --rebase" too.

That I would agree. I am not sure autosquash is the best approach, but we should be able to help them more.