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