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