Jeff King <peff@xxxxxxxx> 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). Yes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html