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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html