Jeff King <p...@peff.net> 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:
> you might have a diff like:
> @@ ... @@ header_A
> + new line 1
> + new line 2
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html