Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"

From: Björn Gustavsson <bgustavsson@gmail.com>
Date: Feb 8, 2010, 07:37 UTC
Message-ID: <6672d0161002072337r2ad002adq69f4c686da8cdf09@mail.gmail.com>
In-Reply-To: <7vbpg060qx.fsf@alter.siamese.dyndns.org>

2010/2/8 Junio C Hamano <gitster@pobox.com>:

Show 10 quoted lines

> You cannot go by the line numbers on the "@@ -l,k +m,n @@" header line you
> see in the second patch you received.  On that line, only k and n are
> reliable numbers (the must match the patch text).  l and m are unreliable;
> being able to apply even if the text you have at hand does not exactly
> match l and m is the whole point of transmitting the change in the patch
> format.  The _only_ information you have usable at that point is that
> there are _at least_ 3 blank lines before the addition, and perhaps the
> fact that the hunk ends without post context lines.  The latter tells you
> that it must apply at the end, but still doesn't tell you how many blanks
> you need to add back at EOF before applying the patch.

I agree. The information is not enough if you apply one patch at the time.

But my usage case that my test tries to demonstrate is different:

I already have a number of commits in my repository (received either by pulling or applying a whole series of patches at once).

I then do, for example:

git rebase --whitespace=fix HEAD~4

to clean up the existing commits.

That rebase uses "git apply" internally seems like an implementation detail that I as a user of rebase don't care about. I just expect it to work.

I see at least two possible ways to implement that:

1. Have "git rebase" give "git apply" a special option so that it
will apply patches beyond the end of file (and trusting the
line numbers in the chunks).

2. Having "git rebase" remember the number of blanks line that
was removed in each previous file in previous fixed commits
and add them back just before invoking "git apply".

It is possible that it is too much work to implement it to be worthwhile (especially solution 2), but I do think it is possible.

If you don't agree, fair enough. In that case I will hold on to the test case and only re-submit it if I can also include a fix.

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB