Sverre Rabbelier <srabbelier@xxxxxxxxx> writes: > On Fri, Feb 13, 2009 at 00:22, Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
