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

Reply via email to