Ramkumar Ramachandra <artag...@gmail.com> writes: > 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.
I do not find this problematic. It shows the user what's going on. It may be a good idea to append the last instructions after launching the editor if we want to partially hide it (but it's still going to be visible with rebase --edit-todo) >> "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? Because "git rebase" needs multiple runs in case of conflicts. You have to store the information somewhere in the filesystem, not in a variable. What you need to store is whether you need to unstash, and where you are in the process (in Junio's version, you may be doing the actual rebase, or fixing conflicts in index state application, or fixing conflicts in tree state application, or done). Storing what you have to do and where you are in the process really sounds like a job for the instruction sheet, no? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
