Jeff King <> writes:

> 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).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to