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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 15, 2013, 16:31 UTC
Message-ID: <CALkWK0kMRm74SOiZ7Jgm2xqS5UEc5HOXQ6F12QqLnhO=QGktew@mail.gmail.com>
In-Reply-To: <7vsj2rzuwl.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 17 quoted lines

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