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

Sverre Rabbelier [off-list ref] writes:

On Fri, Feb 13, 2009 at 00:22, Junio C Hamano [off-list ref] wrote:

quoted

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.

quoted

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.