~sircmpwn/git.sr.ht#357: 
Blame view shards at (arbitrary?) porcelain boundary instead of at SHAs

Consider this blame (L296): https://git.sr.ht/~nabijaczleweli/foreports/blame/14c7148c0cfa0da4d3d2fae30c136c5e4d9c89e2/ar.c#L296 which reads

14c7148c наб 4 months ago  296 int tcmd(void)
08def261 наб 4 months ago  297 {
08def261 наб 4 months ago  298 	if(getaf())
                           299 		noar();

&c. ‒ in multiple places I've found these to be doubled, for no Actual reason. This is odd and confusing, esp. with the side-bar colouring.

A normal blame is as-expected:

14c7148c (наб 2021-09-11 15:10:48 +0200 296) int tcmd(void)
^08def26 (наб 2021-09-11 15:03:21 +0200 297) {
^08def26 (наб 2021-09-11 15:03:21 +0200 298) 	if(getaf())
^08def26 (наб 2021-09-11 15:03:21 +0200 299) 		noar();

But the porcelain one (-p) shards the exact same way (the final number is the amount of lines in a block):

14c7148c0cfa0da4d3d2fae30c136c5e4d9c89e2 296 296 1
	int tcmd(void)
08def261ae73dc292ed344d65ddc45a1787207fd 269 297 1
	{
08def261ae73dc292ed344d65ddc45a1787207fd 271 298 10
		if(getaf())
08def261ae73dc292ed344d65ddc45a1787207fd 272 299
			noar();

Why this shards is beyond me (line number in original/line number now being non-consecutive, maybe, with the 2nd and 3rd numbers?), but it should be relatively simple to weld them in a post-processing step on libgit output.

I'll probably do it, but there's no telling when, so noting this down for future.

Status
REPORTED
Submitter
~nabijaczleweli
Assigned to
No-one
Submitted
2 years ago
Updated
2 years ago
Labels
No labels applied.