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

[Chris Webb <chris@arachsys.com>]

Martin von Zweigbergk <martinvonz@gmail.com> 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.