Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > This option tells rebase--interactive to cherry-pick all the commits in the > rebased branch, instead of fast-forwarding over any unchanged commits. > > Also expanded -f's description in rebase's man page. > > -f offers an alterntive way to deal with reverted merges. Instead of > "reverting the revert" you can use "rebase -f [-i]" 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 -f to handle it. > > Signed-off-by: Marc Branchaud <marcnarc@xxxxxxxxxxx> > --- > > It seems more natural to me to just teach -f to "rebase -i" instead of adding > a new --no-ff option. > > This patch combines my initial "--no-ff" patch with the documentation changes > in my "reword" patch. I moved the unit test for "rebase -f -i" into > t3404-rebase-interactive.sh. Hmm, to be honest, this is not what I expected. A non-interactive "rebase" will _refuse_ to do anything, because it knows that the end result will be exactly the same, in a fast-forward situation. In general, the option "--force" is "I know the precondition I am in will trigger your logic to refuse this request---but please do so anyway", and the use of that option in non-interactive one is in line with that definition. So "--force" makes perfect sense to non-interactive rebase. But "rebase -i" cannot _refuse_ when the range to be rebased is already fast-forward, as the whole point of the command is to be able to rewrite chosen commits, and that "rewriting chosen commits" is the reason why it makes sense for the command to fast-forward the earlier picks that were not chosen to be rewritten. But "forcing" doesn't make sense, if the command does not even refuse to begin with. So "--no-ff" is sensible there. What I meant was that as a measure to prepare for a future merge of (corrected) side branch whose earlier merge was once reverted, it would make sense to use "rebase -f" without any "interactive", compared to the "start rebase -i, and to ensure it wouldn't fast-forward, lie to it that you will reword the first one and do nothing in reality", which your earlier documentation suggested. If anything, teaching --no-ff to non-interactive rebase would also make sense. Just like saying "I know you will refuse if it is a fast forward, but please do so anyway" with --force makes sense, it is sensible to say "I know you will make this a no-op if it is a fast forward, but please rewrite all of them" with --no-ff. -- 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