Re: Editing the root commit

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 22, 2012, 22:50 UTC
Message-ID: <7vhau3m06e.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120622222633.GH25478@arachsys.com>

Chris Webb <chris@arachsys.com> writes:

Show 5 quoted lines

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