GitLogProvider returns no result when filtering for files

Answered

Hi,

I am using VcsLogData::getLogProvider for a given VCS root to find out the commits for a file. To get the actual commits I am calling logProvider::getCommitsMatchingFilter(root, filter, -1), whereas filter is filled ith a struture filter (i.e. VcsLogStructureFilterImpl).

This approach works totally fine for Unix based machines. I get all the commit data I need to solve my issue.

On Windows machines, no commits are returned. When looking for the issue, I found out that GitLogProvider builds filterParameters based on the filePath determined by VcsUtil::getFilePath(VirtualFile).

This filter ends up with a file like "D:\IdeaProjects\myProject\someFile.txt".

When filtering for this file directly on the command line

> git log -- D:\IdeaProjects\myProject\someFile.txt

no commits are returned. When filtering for

> git log -- someFile.txt

all my test commits are found.

On my Ubuntu system GitLogProvider also fills the parameter using the absolute path - however, Git can resolve the files here.

What can I do to make IntelliJ find my commits on a Windows machine? Again - the code works perfectly well on Unix machines. I am also not fussing around with files, but I am just using plain VirtualFiles.

BTW: I tested this with 2017.1 and 2017.2.

Thanks,

Matthias

Edit: Some code for the reading of those commits:

val logProvider = vcsLogData.getLogProvider(root)
val filter = VcsLogFilterCollectionBuilder()
.with(VcsLogStructureFilterImpl(setOf(file)))
.build()

val commits = logProvider.getCommitsMatchingFilter(root, filter, -1)
.map { it.id.asString() }
LOG.info("commitsFor(${file.name}) - commits: $commits")
0
7 comments

Hi, Matthias,

Thanks for reporting the issue. What is the git version you are using under windows?

--

Julia Beliaeva

0
Avatar
Permanently deleted user

Hi Julia,

thanks for your response.

Those are the Git version I currently use:

- Windows: 2.12.3
- Ubuntu: 2.11.0

I wonder whether Git removed support for absolute paths?

Thanks,

Matthias

0
Avatar
Permanently deleted user

Hi Julia,

just to keep you up to date: Overiding the #getFiles method and returning the relative paht fixes the issue for me. However, this behaviour looks like a bug within the OpenAPI to me.

Matthias 

0

Hi, Matthias,

Sorry for the late answer.

I could not reproduce problems with full paths for windows git of 2.12.2(3) and 2.14.1 versions. I could though find a stackoverflow post where author complains about full paths not working in 1.7.0.5.

However, you are correct, we should form a command with relative paths. I'm going to fix this.

By the way, I have to warn you that method `getCommitsMatchingFilter` does not follow file renames.

--

Julia

0
Avatar
Permanently deleted user

Hi Julia,

Thank you so much ;-) I'll be happy to try out any new versions of idea!
Any recommendations as replacement for getCommitsMatchingFilter? Actually, I did only look for some method getting me the history of files.
Matthias

0

Matthias,

You can get an instance of `VcsHistoryProvider` for your repository and retrieve history from it. Like this:

AbstractVcs vcs = ProjectLevelVcsManager.getInstance(project).getVcsFor(root);
if (vcs != null) {
VcsHistoryProvider provider = vcs.getVcsHistoryProvider();
if (provider != null) {
VcsAppendableHistoryPartnerAdapter partner = new VcsAppendableHistoryPartnerAdapter();
provider.reportAppendableHistory(filePath, partner);
return partner.getSession().getRevisionList();
}
}

Where `project` is a current project, `root` is a repository root, `filePath` is a file. You can also implement your own partner to get revisions one by one as git loads them.

--

Julia

0
Avatar
Permanently deleted user

Cool thanks, then I'll change my implementation ;-)

Matthias

0

Please sign in to leave a comment.