From: Jonathan Nieder <jrnieder@gmail.com>
Date: Wed, 23 Jul 2014 17:52:18 GMT
Subject: Re: rebase flattens history when it shouldn't?
Message-ID: <20140723175218.GB12427@google.com>
In-Reply-To: <87k374xkpq.fsf@osv.gnss.ru>

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