Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> At what point in what valid workflow sequence does HEAD become different
>> from dotest/amend?
>
> $ rebase -i HEAD~5
>
> <mark one commit as edit>
>
> <Whoa! While editing, I realize that this contains an unrelated
> bugfix>
>
> $ git reset HEAD^
> $ git add -p
> $ git commit
>
> <Edit a bit here, a bit there>
>
> $ git rebase --continue
>
> Sure it is a pilot error. It hit this pilot, too.
> ...
> In the way that the user certainly did not mean to amend _this_ HEAD.
> Another HEAD was marked with "edit".
Ok; after this "refraining from incorrectly squashing them", how would the
user edit the one the user originally intended to edit (I am not
complaining, but asking for information)?
So in your workflow example, when there is no pilot error, is this the
"ideal" sequence?
$ git rebase -i HEAD~5
.. mark one as edit
.. ah, the one I wanted to just "edit" actually need to be
.. split into two because it has some other thing I need to change
$ git reset HEAD^
$ git add -p
$ git stash --keep-index
.. test to verify the initial part
$ git commit ;# first part of split commit
$ git stash pop
.. test test
$ git add -p
$ git rebase --continue ;# gives you the editor to edit
I wonder if we can make the transcript of the "pilot error" case look like
this:
$ git rebase -i HEAD~5
...
$ git reset HEAD^
.. same as above up to...
.. test to verify the initial part
$ git rebase --continue ;# oops
.. gives you the editor to edit the message.
.. makes a commit, and says:
committed initial part of the change, stopping.
.. ah, the command noticed it and did not escape, thanks!
$ git stash pop
.. test test
$ git add -p
$ git rebase --continue ;# gives you the editor to edit
.. and goes on this time.
--
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
