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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 15, 2013, 18:08 UTC
Message-ID: <CALkWK0=6E=s6kJysMo2yC22c3pvCWn90S5neRyP0jpzpYrZboA@mail.gmail.com>
In-Reply-To: <7vr4ibu14j.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 7 quoted lines

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