Re: Editing the root commit

Chris Webb [off-list ref] writes:

Ignoring the implementation, I think the nastiest bit here is what happens
for the user if there's a conflict, as Peff pointed out. Ideally, we want to
checkout a state we're going to replay the patch onto, so that if we drop
out because there's conflict (e.g. the patch modifies a file which doesn't
exist yet), git diff and git diff --cached do something sensible.

Step back a bit.

If you are doing "rebase -i --root", what does it _mean_ to reorder
commits and move the root commit to somewhere else, or insert
something else that is _not_ the root to the beginning of the
sequence?

It does not make _any_ sense to me.  For one thing, the root commit
is to replay "addition of all these paths" to void (if you were doing
"rebase -i --root --onto $there", then $there may not be a void, but
it needs not to have overlapping paths for the result to make any
sense), and moving it to somewhere _other than_ the root location
does not make much sense.  For another, a non-root commit is mostly
replay "these changes to these existing paths", and replaying such a
change to a void does not make any sense either.

So in that sense, perhaps

	rebase -i --root

in a history

	A---B---C

should behave as if you did

	rebase -i A

got an insn sheet that looked like

	pick B
        pick C

and then you made it to look like

	exec false
        pick B
        pick C

to get the control back when the HEAD is detached at A, in order for
you to muck with the tree and "git commit --amend" to reword the
message.