Re: rebase flattens history when it shouldn't?

From: Sergei Organov <osv@javad.com>
Date: Jul 23, 2014, 19:33 UTC
Message-ID: <8738drj2fc.fsf@osv.gnss.ru>
In-Reply-To: <20140723175218.GB12427@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 35 quoted lines

> 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.

What actually bothers me is the unfortunate consequence that "git pull" is not always a no-op when nothing was changed at the origin since the last "git pull". THIS is really surprising and probably should better be fixed. Requiring -f is just one (obvious) way to fix this.

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

I can't suggest anything as I don't see why -f is there in the first place. What are use cases?

-- 
Sergey.