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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2013, 17:58 UTC
Message-ID: <7vr4ibu14j.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0=cNEkE0bUoWJg119o+FaQywJhgkUxiFfLGPSsLrFVZ=A@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 10 quoted lines

> Junio C Hamano wrote:
>>         git-rebase --autostash
>>
>>                 git commit --allow-empty -m 'index part'
>>                 git commit --allow-empty -a -m 'working tree part'
>>                 git rebase --onto $UPSTREAM
>>                 git reset HEAD^
>>                 git reset --soft HEAD^
>
> Why are you rolling your own stash?  What do you have against git stash?

Nothing. It just felt that it does not _have to be_ implemented with stash, and explaining things in terms of commit and reset would be simpler.

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.

Then the usual "rebase --continue" would just work. Instead you could use "git stash" at step #2 and add "exec git stash pop" at step #3.

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