Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> 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.
>> 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.
>> 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".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html