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