-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to fetch git blame info on specific files #155
Comments
Confirmed the last commit on that file was a merge commit:
|
Hi, i have the same issue. |
Seems to be also related/duplicated by below issues:
For me it also fails as described above in both cases: a) when running on merge request and b) when running after the merge request on master. I am using GitLab. Below is job configuration I am using
Here is my CI output:
|
I have a slightly different problem. The error message reads |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The problem is still there ... |
Just adding that I am running into this problem as well in GitHub Actions:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The problem is still there. ... |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The problem is still there. ... |
I'm debugging the very same issue. It looks like a The In func Blame(c *object.Commit, path string) (*BlameResult, error) {
b := new(blame)
b.fRev = c
b.path = path
// get all the file revisions
if err := b.fillRevs(); err != nil {
return nil, err
} The // calculate the history of a file "path", starting from commit "from", sorted by commit date.
func (b *blame) fillRevs() error {
var err error
b.revs, err = references(b.fRev, b.path)
return err
} In func references(c *object.Commit, path string) ([]*object.Commit, error) {
var result []*object.Commit
seen := make(map[plumbing.Hash]struct{})
if err := walkGraph(&result, &seen, c, path); err != nil {
return nil, err
}
// TODO result should be returned without ordering
sortCommits(result)
// for merges of identical cherry-picks
return removeComp(path, result, equivalent)
} You would find that Let's drill down into func walkGraph(result *[]*object.Commit, seen *map[plumbing.Hash]struct{}, current *object.Commit, path string) error {
// check and update seen
if _, ok := (*seen)[current.Hash]; ok {
return nil
}
(*seen)[current.Hash] = struct{}{}
// if the path is not in the current commit, stop searching.
if _, err := current.File(path); err != nil {
return nil
}
// optimization: don't traverse branches that does not
// contain the path.
parents, err := parentsContainingPath(path, current)
if err != nil {
return err
}
switch len(parents) {
// if the path is not found in any of its parents, the path was
// created by this commit; we must add it to the revisions list and
// stop searching. This includes the case when current is the
// initial commit.
case 0:
*result = append(*result, current)
return nil
case 1: // only one parent contains the path
// if the file contents has change, add the current commit
different, err := differentContents(path, current, parents)
if err != nil {
return err
}
if len(different) == 1 {
*result = append(*result, current)
}
// in any case, walk the parent
return walkGraph(result, seen, parents[0], path)
default: // more than one parent contains the path
// TODO: detect merges that had a conflict, because they must be
// included in the result here.
for _, p := range parents {
err := walkGraph(result, seen, p, path)
if err != nil {
return err
}
}
}
return nil
} It traversed the whole git commits tree, filter out commits those are related to the current file, uses The problem is: default: // more than one parent contains the path
// TODO: detect merges that had a conflict, because they must be
// included in the result here.
for _, p := range parents {
err := walkGraph(result, seen, p, path)
if err != nil {
return err
}
}
} For a merged commit, it has two parent commits, but in this block it forgot to check the I'll try to commit a pr to |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Do you plan to take a look at this? If not, I will stop trying to keep this problem in open status. |
Hi @gustavoortega, |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Should stay open. The mentioned PR has been merged a couple of days ago. |
@kayman-mk Thanks for the update! Really good news, once |
By using the latest version of the lib from "master" this PR fixed my issue. Thank you very much @onegunmanb!! 🎉🎉 |
Glad to hear that @flaviostutz , now we need to wait for a new |
@lonegunmanb v5.8.1 is out as I just noticed. |
Any update on this? 🙏 |
@oponomarov-tu I think once #375 has been merged or |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still waiting for #375 |
I found that #375 failed at the "security scan" step, I'll take a look but since I cannot access the CI log details, I'm not sure whether I can fix the issue. |
I tried something else today as I saw a warning from Sonar that I used an shallow clone. Adding a |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Should stay open. |
Should stay open |
@nimrodkor Most of my git tagging issues have been resolved after #147, however it seems like one of the files in the sub-dir I tested this on was still unable to fetch git blame info:
You can see that one of the resources was only tagged with
yor_trace
:Not sure what
error contents and commits have different length
means. From slack:Originally posted by @mwarkentin in #147 (comment)
The text was updated successfully, but these errors were encountered: