JGIT blame doesn't emit revision/author for some lines causing a mismatch for all following lines

[aerofeev2k]

I'm seeing an issue with a mismatch between second/third columns (containing revision number and author) in OpenGrok Annotate page and actual file contents for GIT files.

It appears that for some commits revision/author entries are not emitted, meaning that:

1. Though the file's line is output, the corresponding revision/author is not;
2. As a result, for the rest of the file revision/author are shifted up by one line;
3. At the end of the Annotate page the last line of the file has empty revision/author.

"git blame" has no problem showing correct info.

It seems that the two things that are different about the commits that cause the mismatch is a space in the developer's name and a different timezone (as reported by "git blame"). Some commits are just trivial single line insertions.

Has anything like that been seen and perhaps fixed in the last year? Is it possible to switch OpenGrok to using "git blame" command rather than JGIT for generating Annotate pages through some config setting?

I tried replacing org.eclipse.jgit-5.12.0.202106070339-r.jar with a newer 7.0 version, but that didn't really make any difference.

Thanks!

[vladak]

If you could come up with a simple reproducible scenario/repository, that would be great.

The JGit use by the GitRepository is hard-coded and cannot be changed. I am now aware of any major changes to GitRepository in the last couple of years that would affect the annotate view, maybe besides the annotation cache (which is disabled by default and should not affect the way how annotate is displayed functionally).

[aerofeev2k]

Well, another commit was done today, and things got magically fixed. I now think that it may be related to merge commits because they're not shown in OpenGrok history, and yesterday it was a merge commit on the tip, according to "git log", and something else, according to OpenGrok.

[aerofeev2k]

Yeah, just noticed this with another file that has a merge commit on the tip. So, is this happening because when OpenGrok is doing "git blame", it's doing it against the last non-merge commit that it sees in the history, but when displaying the annotation results it's using source code that currently sits in the current directory (and includes the merge commit changes)? Hence the discrepancy between annotations and source code?

[aerofeev2k]

Interestingly, this doesn't happen when I refer to the revision, for which annotations are to be displayed, by a long hashtag. E.g. a "?a=true&r=c29bb9b5" would show revision numbers and developer names not matching source code, but "?a=true&r=c29bb9b57" or "?a=true&r=c29bb9b575c89fbde394e76b5cbd78d3e5ff66cc" would work perfectly well.

[vladak]

I believe the recent versions always use long hash to construct the URLs.

[aerofeev2k]

It appears to be not related to hashtag lengths after all, it's still the merge commits.

I have two last revisions of the file that show up in "git log": latest one is a 22379-line long merge commit 398df8c42136931eb2161f1c1b3bf53d0f29978d and previous one is 22342-line long regular commit c29bb9b575c89fbde394e76b5cbd78d3e5ff66cc.

OpenGrok 1.7 doesn't show merge commits in the history at all, it's as if they didn't exist. So when I go and look at the annotations, it's passing "?r=c29bb9b5" (i.e. the hashtag of the last non-merge commit) and is fetching 22342-line long annotations corresponding to the the last regular commit c29bb9b575c89fbde394e76b5cbd78d3e5ff66cc. But somehow the source code is 22379-byte long and is actually from the tip. This produces a mismatch.

When I start extending or shrinking hashtag c29bb9b5, cfg.isLatestRevision(rev) in list.jsp stops returning true, and I do get a perfect match between annotations and source code, however, it's still a match for the last non-merge revision c29bb9b575c89fbde394e76b5cbd78d3e5ff66cc, rather than the tip 398df8c42136931eb2161f1c1b3bf53d0f29978d.

Did OpenGrok's treatment of merge commits improve since 1.7, does it make sense for me to upgrade to the latest at this point?

[aerofeev2k]

And raising mergeCommitsEnabled=true in configuration.xml fixes everything, I didn't know that this option existed.

Maybe it should be ON by default, if w/o it tip annotations aren't working properly? Or perhaps even with mergeCommitsEnabled=false, OpenGrok should still show and use the merge commit on the tip, because in this case it's not just noise, it corresponds to the tip of the branch and is therefore essential?

[vladak]

Maybe it should be ON by default, if w/o it tip annotations aren't working properly? Or perhaps even with mergeCommitsEnabled=false, OpenGrok should still show and use the merge commit on the tip, because in this case it's not just noise, it corresponds to the tip of the branch and is therefore essential?

Merge commits were enabled by default with 2bbcff65, since 1.12.0