git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Björn Gustavsson" <bgustavsson@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"
Date: Mon, 8 Feb 2010 08:37:19 +0100	[thread overview]
Message-ID: <6672d0161002072337r2ad002adq69f4c686da8cdf09@mail.gmail.com> (raw)
In-Reply-To: <7vbpg060qx.fsf@alter.siamese.dyndns.org>

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

> 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

  reply	other threads:[~2010-02-08  7:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-07  8:10 [PATCH] Add a test for a problem in "rebase --whitespace=fix" Björn Gustavsson
2010-02-07 18:38 ` Junio C Hamano
2010-02-07 22:44   ` Björn Gustavsson
2010-02-08  0:15     ` Junio C Hamano
2010-02-08  7:37       ` Björn Gustavsson [this message]
2010-02-09 21:58         ` Junio C Hamano
2010-02-10 20:20           ` Björn Gustavsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6672d0161002072337r2ad002adq69f4c686da8cdf09@mail.gmail.com \
    --to=bgustavsson@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).