Hi, On Fri, 25 Jul 2008, Junio C Hamano wrote: > 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)? In this case, the two commits are two commits, the editor popped up with rebase --continue contains the original commit message, and all is fine. > 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 Without pilot error, here has to come a "git commit -c HEAD@{1}". > $ 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. Possible. The first hunk (IIRC) of my patch would stay the same, but the second hunk would not fall through to the interactive commit, instead testing if amend exists, _and_ is different from HEAD, and if both are the case, say something helpful and exit. Ciao, Dscho -- 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