Re: rebase flattens history when it shouldn't?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 23, 2014, 17:52 UTC
Message-ID: <20140723175218.GB12427@google.com>
In-Reply-To: <87k374xkpq.fsf@osv.gnss.ru>

Hi Sergei,

Sergei Organov wrote:

Show 11 quoted lines

>      --C--
>     /     \
>    /   ----M topic,HEAD
>   /   /
>  A---B master
>
> shouldn't
>
> $ git rebase master
>
> be a no-op here?

[...]

Show 7 quoted lines

> 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