Chris Webb <chris@xxxxxxxxxxxx> 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.
--
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