Jonathan Nieder <jrnie...@gmail.com> writes:
> Hi Sergei,
> Sergei Organov wrote:
>> / \
>> / ----M topic,HEAD
>> / /
>> A---B master
>> $ 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
>> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html