From: Ramkumar Ramachandra Date: Mon, 15 Apr 2013 16:31:53 GMT Subject: Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash Message-ID: In-Reply-To: <7vsj2rzuwl.fsf@alter.siamese.dyndns.org> 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.