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

[John Keeping <john@keeping.me.uk>]

On Mon, Apr 15, 2013 at 11:38:20PM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > If "rebase -m" were to be taught to do this, the natural way to do
> > so is to
> >
> >   (1) Prepare the todo the usual way
> >   (2) Do those two commits for index and working tree
> >   (3) Append two insns (exec reset HEAD^ and exec reset --soft
> >       HEAD^) at the end of the rebase todo file.
> 
> Er, no.  I don't want to touch the instruction sheet.  It becomes
> especially problematic in -i, when the instruction sheet is
> user-editable.
> 
> > "rebase--am" could also be told to generate (on the preparation
> > side) and notice (on the application side) a pair of patch files at
> > the end that represent the index state and the working tree state
> > and apply them without making the WIP part into a commit.
> 
> Ugh, no.  I don't want to leak the implementation detail of autostash
> into specific rebases.  Why can't I wrap the last statment in
> git-rebase.sh in git stash/ git stash pop like I did with git-pull.sh?

How does that work with the following:

- run_specific_rebase fails, so the user needs to fix it up and then run
  "git rebase --continue".  We don't want to pop the stash in this case.

- the user runs "git rebase --continue" with staged changes, knowing the
  git-rebase will commit those.  We don't want to create a stash in this
  case since it will remove the changes the user wants to commit.