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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2013, 15:16 UTC
Message-ID: <7vsj2rzuwl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mmrvYSjvUCvvjbnav4JmbkVKho2K6c7QAM2AuqWFkEFw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 22 quoted lines

> Junio C Hamano wrote:
>> In the end, simple cases (the canonical example being Linus keeping
>> a local change to "Name = Unicycling Gorilla" in his Makefile while
>> running dozens of "git pull" every day) would not be helped with
>> this feature very much because there is rarely overlap, while in a
>> complex case the user really needs help to save away his WIP, the
>> user is forced to resolve the conflict immediately upon the failed
>> "stash pop" at the end of "git pull".  If the conflict turns out to
>> be something the user would not want to resolve at that moment, the
>> user needs to know the way out, something like:
>>
>>         git reset --hard                ;# go back to the result of pull
>>         git checkout -b wip ORIG_HEAD   ;# start from before the pull
>>         git stash pop                   ;# recover his wip
>>         ... perhaps work a bit more ...
>>         git commit -a -m wip            ;# save it away for safety
>>         git checkout -                  ;# result of pull
>>
>> so that he can come back tomorrow, check out "wip" branch, and
>> decide what to do.
>
> What does this have to do with pull at all?

Exactly.

By tempting the user to use autostash first, you are forcing the user to say "reset --hard" (the first one), "ORIG_HEAD" (to start from the pre-pull state), "stash pop" (to recover the autostashed WIP), to a user who got conflict during "stash pop" after the pull integrated the committed work with the remote side.

If the user did this instead:

        ... Let's save my large WIP away in a more permanent place first
	git checkout -b wip
        ... perhaps work a bit more ...
        git commit -a -m wip
        git checkout -
	... and then ...
	git pull

the user wouldn't have had to do those extra steps.

Another thing to consider is that even with the current system, many users do not have a clear idea on what the state of the working tree is when a "pull" fails (there are largely two classes). Either the merge failed without damaging the WIP before the pull at all, or there wasn't any interaction between the WIP and the change pull wanted to bring in and only the paths with conflicts need to be resolved and added (i.e. "commit -a" is a no-no). This "auto-pop" adds a third failure mode to "pull". It is a non-issue for Git-heads like us (we do read the messages from the programs), but not all users are like us.

Show 6 quoted lines

>> The "--autosquash" option (or not adding either the configuration or
>> the option) would encourage the user to think about the nature of
>> WIP he has in the working tree before running "git pull".
>
> I'm lost.  What does git rebase --autosquash (or rebase.autosquash)
> have anything to do with git pull --autostash?

Sorry, the typo meant --autostash.

Show 9 quoted lines

>> Is it a
>> too complex beast that may interfere with what others are doing, or
>> is it a trivial change that he can stash away and pop it back?  If
>> the former, he will be far better off doing "checkout -b", keep
>> working until the local change gets into somewhat a better shape and
>> "commit", before pulling into the original branch.
>
> A pull-merge person having complex worktree changes should not execute
> git pull blindly in the first place.   That's what git fetch is for:

Huh?  You are not making sense.

I would understand it if it were "That's what git commit is for", though.

> But I'm a pull-rebase guy, and I always want pull.autostash.

That is why I said the equation is different for pull-rebase, where "rebase" insists that you start from a squeaky clean working tree, so you can check the condition early before "git pull" even starts. While --autostash will not improve the life for pull-merge people (and pull.autostash will actively hurt them), pull.autostash does help pull-rebase people work around the limitation of "rebase".