Sergey Organov <> writes:

> ... I.e., git must not rebase anything
> when "Current branch is a descendant of the commit you are rebasing
> onto", unless -f is given. Simple, reasonable, straightforward.

It may be simple and straightforward, but breaks the use case the
plain vanilla rebase is used for, doesn't it?  You seem to ignore,
or perhaps you don't realize the existence of, the need of those who
want to flatten the history on top of the tip from the other side;
your statements in the "pull --rebase[=preserve]" thread may be
coming from the same place, I suspect.

For the "flatten the history on top of that commit" use case, two
conditions must be satisfied before the command can say "the history
is already in the desired shape and nothing needs to be done" to
allow it to make a short-cut.  It is not sufficient for the current
tip to be merely descendant of the tip from the other side (which is
the documentation bug we are fixing here).  The history between the
two commits need also to be linear, or it would not be flattening.

Punting when when only one of the two conditions is met and
requiring "--force" to perform what the user wanted to ask the
command to do does not fall into the "reasonable" category.

If your workflow does not involve the flattening plain vanilla
"rebase", not using it is perfectly fine.  But please do not break
it for other people only because you do not use it yourself.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to