Subject: Re: rebase flattens history when it shouldn't?

From: Jonathan Nieder <[email-masked]>
Date: Wed, 23 Jul 2014 10:52:18 -0700

Hi Sergei,

Sergei Organov wrote:

>      --C--
>     /     \
>    /   ----M topic,HEAD
>   /   /
>  A---B master
> shouldn't
> $ git rebase master
> be a no-op here?
[...]
> I'd expect --force-rebase to be required for this to happen:
>
> -f, --force-rebase
>     Force the rebase even if the current branch is a descendant of the
>     commit you are rebasing onto. Normally non-interactive rebase will
>     exit with the message "Current branch is up to date" in such a
>     situation.
[...]
> Do you think it's worth fixing?

Thanks for a clear report.

After a successful 'git rebase master', the current branch is always a
linear string of patches on top of 'master'.  The "already up to date"
behavior when -f is not passed is in a certain sense an optimization
--- it is about git noticing that 'git rebase' wouldn't have anything
to do (except for touching timestamps) and therefore doing nothing.

So I don't think requiring -f for this case would be an improvement.

I do agree that the documentation is misleading.  Any ideas for
wording that could make it clearer?

Hope that helps,
Jonathan