Re: [PATCH] git-add--interactive: Preserve diff heading when splitting hunks

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2014, 21:07 UTC
Message-ID: <xmqqvbtapuyk.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140512183955.GB31164@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 30 quoted lines

> One, there is a slightly funny artifact in that the hunk header comes
> from the top of the context line, and that top is a different position
> for each of the split hunks. So in a file like:
>
>   header_A
>       content
>   header_B
>       one
>       two
>       three
>       four
>
> you might have a diff like:
>
>   @@ ... @@ header_A
>    header_B
>        one
>        two
>   +    new line 1
>        three
>   +    new line 2
>        four
>
> The hunk header for "new line 1" is "A", because "B" itself is part of
> the context. But the hunk header for "new line 2", if it were an
> independent hunk, would be "B". We print "A" because we copy it from the
> original hunk.
>
> It probably won't matter much in practice (and I can even see an
> argument that "A" is the "right" answer).

I tend to agree with both points.

> And figuring out "B" here
> would be prohibitively difficult, I would think, as it would require
> applying the funcname rules internal to git-diff to a hunk that git-diff
> itself never actually sees.

You can actually apply a split hunk being proposed to a temporary file and then ask "git diff" about it, so I do not think difficult is too much of an issue, but I doubt we would want to see header_B, exactly because when the user says "Split this hunk", s/he is very well aware that the second one is artificial and was split from the original hunk whose header said header_A.

> Since the output from your patch is strictly better than what we saw
> before, I think there is no reason we cannot leave such an improvement
> to later (or never).

Yes.