jenkinsci / jenkinsci/git-forensics-plugin
Git blame is skipped for shallow clones regardless of depth
- Dominant language
- Java
- Stars
- 43
- Forks
- 29
- Avg merge
- 5d 12h
- Merged PRs (30d)
- 5
Description
### What feature do you want to see added?
We use shallow clone with depth 100 for performance reasons (our repositories have large histories). The plugin unconditionally skips blame when CloneOption.isShallow() is true, regardless of the configured depth:
```
[CheckStyle] Creating SCM blamer to obtain author and commit information for affected files
[CheckStyle] Skipping issues blame since Git has been configured with shallow clone
[CheckStyle] -> Git blamer could not be created for SCM 'hudson.plugins.git.GitSCM@66c225b2' in working tree '/home/ec2-user/jenkins/workspace/adminpanel'
[CheckStyle] -> No suitable blamer found.
```
Git blame works correctly on shallow clones with depth > 1 — it simply attributes lines older than the available history to the boundary commit. For our use case (identifying who introduced a new warning recently), a depth of 50-100 is more than sufficient.
The check in GitRepositoryValidator.isShallow() only looks at whether the shallow option is enabled, not at the depth value:
```
private boolean isShallow(final GitSCM git) {
var option = git.getExtensions().get(CloneOption.class);
return option != null && option.isShallow();
}
```
Would it be possible to allow blame on shallow clones with depth > 1, or provide a configuration option to opt-in?
Environment: Jenkins 2.572, Git Forensics Plugin 4.2416.v46d45e29f28f, Warnings NG Plugin 13.10153.v011f47a_3ef01, Git Plugin 5.10.1
### Upstream changes
_No response_
### Are you interested in contributing this feature?
_No response_
Contributor guide
Research direction
Start with GitRepositoryValidator.isShallow() and inspect how CloneOption.isShallow() and its configured depth are used when creating the Git blamer. Check the plugin's existing tests or add focused coverage for shallow clones at depth 1 and greater than 1. Done means blame remains available for supported shallow depths or an explicit opt-in behavior is implemented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, java
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100