Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f

[Junio C Hamano <gitster@pobox.com>]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> On Fri, Feb 13, 2009 at 00:22, Junio C Hamano <gitster@pobox.com> wrote:
>> No, because I didn't read the patch text; I don't read patches that are
>> larger than 20 lines during the day-job hours.
>
> Hehe, that sounds like a fair policy.
>
>> I was only commenting on your "rebase does not work if I am up to date
>> with respect to origin and here is my workaround".
>
> Ok, thanks for the comment then, I'll wait for more comment and maybe
> write some tests tomorrow.

Ok, now it is past 5pm, I've read the patch.

I wonder if we can (and if so should) make this a bit more automatic
without having to say "rebase -f --whitespace=fix".

When you say "git rebase --whitespace=fix origin" from the command line,
you are explicitly saying "I want to *fix* breakages in the commits since
'origin'", and at that point, it stops mattering if origin stayed dormant
since you forked from it.  I'd say that the current behaviour is a bug
introduced by the commit that added --whitespace=fix option.

The logic is the same as "git rebase --interactive origin" that does not
refuse to work even if you are already ahead of the origin.

So my suggestion would be to add --force (or -f) like your patch does, and
also detect --whitespace=$option given from the command line, and if it is
fix (or its synonym "strip"), automatically enable --force, perhaps as a
follow up patch, or in the same patch.