Web lists-archives.com

Re: Is rebase --force-rebase any different from rebase --no-ff?

On 2018-05-09 02:21 PM, Stefan Beller wrote:
+cc Marc and Johannes who know more about rebase.

On Wed, May 9, 2018 at 9:01 AM, Ilya Kantor <iliakan@xxxxxxxxx> wrote:
Right now in "git help rebase" for --no-ff:
"Without --interactive, this is a synonym for --force-rebase."

But *with* --interactive, is there any difference?

I found
from 2010-03-24

In the original discussion around this option [1], at one point I proposed teaching rebase--interactive to respect --force-rebase instead of adding a new option [2]. Ultimately --no-ff was chosen as the better user interface design [3], because an interactive rebase can't be "forced" to run.

At the time, I think rebase--interactive only recognized --no-ff. That might have been muddled a bit in the migration to rebase--helper.c.

Looking at it now, I don't have a strong opinion about keeping both options or deprecating one of them.


[1] https://public-inbox.org/git/4B9FD9C1.9060200@xxxxxxxxxxx/t/
[2] https://public-inbox.org/git/1269361187-31291-1-git-send-email-marcnarc@xxxxxxxxxxx/
[3] https://public-inbox.org/git/7vzl1yd5j4.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/

     Teach rebase the --no-ff option.

     For git-rebase.sh, --no-ff is a synonym for --force-rebase.

     For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in
     the rebased branch, instead of fast-forwarding over any unchanged commits.

     --no-ff offers an alternative way to deal with reverted merges.  Instead of
     "reverting the revert" you can use "rebase --no-ff" to recreate the branch
     with entirely new commits (they're new because at the very least the
     committer time is different).  This obviates the need to revert the
     reversion, as you can re-merge the new topic branch directly.  Added an
     addendum to revert-a-faulty-merge.txt describing the situation and how to
     use --no-ff to handle it.

which sounds as if there is?