Re: [PATCH] new test fails "add -p" for adds on the top line

From: Thomas Rast <trast@student.ethz.ch>
Date: May 16, 2009, 14:12 UTC
Message-ID: <200905161612.30911.trast@student.ethz.ch>
In-Reply-To: <20090516192529.6117@nanako3.lavabit.com>

Nanako Shiraishi wrote:

Show 24 quoted lines

> Quoting Matt Graham <mdg149@gmail.com>:
> 
> > add -p doesn't work for some diffs.  diffs adding a new line at the top of
> > the file with other adds later in the file are one way to trigger the problem.
> >
> > during add -p, split the diff and then answer y for all segments.  the file
> > won't have been added to the index.
> >
> > Signed-off-by: Matthew Graham <mdg149@gmail.com>
> 
> I tried "git-add -p" from different versions and I found out that versions before the commit 0beee4c6dec15292415e3d56075c16a76a22af54 doesn't have this problem.
> 
> commit 0beee4c6dec15292415e3d56075c16a76a22af54
> Author: Thomas Rast <trast@student.ethz.ch>
> Date:   Wed Jul 2 23:59:44 2008 +0200
> 
>     git-add--interactive: remove hunk coalescing
>     
>     Current git-apply has no trouble at all applying chunks that have
>     overlapping context, as produced by the splitting feature. So we can
>     drop the manual coalescing.
>     
>     Signed-off-by: Thomas Rast <trast@student.ethz.ch>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>

The above commit still reverts cleanly, but AFAICS merge_hunk blindly trusts the hunk headers, an assumption that is no longer valid due to the 'edit' feature. So either we need to recount the hunk headers prior to merging (which was rejected back in the 'edit' feature discussion due to code complexity) or find some other solution.

Passing either --unidiff-zero or -C1 with the failing patch fixes the problem, but oddly (to me at least) -C2 does not. The generated error looks like

  $ git apply --check -v -C2 < patch
  Checking patch file...
  error: while searching for:
  baseline
  content

  error: patch failed: file:1
  error: file: patch does not apply

The corresponding call (builtin-apply.c:2093) is

			error("while searching for:\n%.*s",
			      (int)(old - oldlines), oldlines);

so it does not seem to insert the extra newline. Is it actually looking for a blank line in the context? If so, wouldn't that be a git-apply bug?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch