Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2014, 16:48 UTC
Message-ID: <xmqqha1g49q5.fsf@gitster.dls.corp.google.com>
In-Reply-To: <87mwb8ahtb.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> 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.