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

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

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.

quoted

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.

quoted

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

Junio C Hamano wrote:

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.

Hm, yes.  For a pull-merge guy who opts for pull.autostash, the
penalty for forgetting to commit a big WIP in advance is too high.  It
probably makes sense to restrict the autostash feature to kick in only
in the rebase codepath: it might be a good idea to implement
rebase.autostash for reduced case of non-interactive rebases instead.
I'm only slightly iffy about --onto, but it's not a big concern.