From: Thomas Rast <trast@student.ethz.ch>
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: Matt Graham <mdg149@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] new test fails "add -p" for adds on the top line
Date: Sat, 16 May 2009 16:12:22 +0200 [thread overview]
Message-ID: <200905161612.30911.trast@student.ethz.ch> (raw)
In-Reply-To: <20090516192529.6117@nanako3.lavabit.com>
[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]
Nanako Shiraishi wrote:
> 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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-05-16 14:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-16 3:10 [PATCH] new test fails "add -p" for adds on the top line Matt Graham
2009-05-16 10:25 ` Nanako Shiraishi
2009-05-16 14:12 ` Thomas Rast [this message]
2009-05-16 17:48 ` Junio C Hamano
2009-05-16 17:55 ` Sverre Rabbelier
2009-05-16 19:13 ` Junio C Hamano
2009-05-16 19:14 ` Sverre Rabbelier
2009-05-16 19:51 ` Junio C Hamano
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=200905161612.30911.trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=mdg149@gmail.com \
--cc=nanako3@lavabit.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).