Re: [RFC PATCH] add t3420-rebase-topology

Martin von Zweigbergk [off-list ref] writes:

For consistency, it seems like "git rebase -p --root" should always be
a no-op, while "git rebase [-i/-m] --root" should be no-op if the
history has no merges. Also, since "git rebase -i" tries to
fast-forward through existing commits, it seems like "git rebase -i
--root" should ideally not create a sentinel commit, but instead stop
at the first commit marked for editing.

If, OTOH, --force-rebase is given, we should rewrite history from the
first commit, which in the case of --root would mean creating a
sentinel commit.

So, in short, I have a feeling that the sentinel commit should be
created if and only if both --root and --force-rebase (but not --onto)
are given.

[...]

So I'm getting more and more convinced that the sentinel commit should
only be created if --force-rebase was given. Let me know if I'm
missing something.

No, that sounds fairly convincing to me. Personally, the only behaviour I
want to be able to get at without --force-rebase is for rebase -i --root to
allow the root commit to be dropped, edited or reworded, and commits to
reordered to make a different one the root, in the same way as normal
interactive rebase does for later commits.

The least intrusive implementation for rebase --root was the unconditional
sentinel, but as you say, you don't need it (and it's a bit surprising) if
the root commit on the instruction sheet is the same as the original root:
in the edit/reword case, you could just checkout the existing root and then
drop out in the normal way. You only really need the sentinel to deal with
the possibility of a conflict if the root is replaced with a different
commit.

I think I agree with you it would be better only to create the sentinel on
demand when it's required or if --force is given.

Cheers,

Chris.