Question: How to get the last commit that affected a given file

[fbezdeka]

Hi @ALL.

I'm searching for a method that will return the last commit that affected a given file.

I looked through the API but I did not find a method that seems to do it.

First question: Was the solution overlooked?
Second question: How to get the last commit?

Thanks.

[nulltoken]

@Flonix,

Hey. It looks like you after something like git log -1 --follow FILENAME

First question: Was the solution overlooked?

No. This isn't implemented yet.

Second question: How to get the last commit?

Easy peasy. It's a two steps process:

Step One:

• Create failing tests you'd like to see pass

Step Two:

• From the filename, retrieve the Sha1 of the matching Blob in the object database
• ... some code...
• Recursively walk the parent commits of the Head (beware of the merges)
  • Detect renames (same Sha, different names, (beware of file duplication use case))
  • ... more code ...
  • Identify changes (same name, different Shas)
  • ... find some new corner case tests to handle. Add them...
  • ... still coding ...
• Find a nice API name to wrap this in :)
• Push to a new branch and open a Pull Request
• Unlock the achievement "Awesome contribution!" 🆒

[fbezdeka]

@nulltoken,

That is exactly what I am searching for.
I hoped that it is already implemented...

I will look at it in a few days. Maybe I am able to solve that.

Thanks so far...

[shytikov]

Hey, @Flonix please take a look on our discussion with @nulltoken on StackOverflow. I'm plan to implement approach I mentioned there and share Gist with you.

[fbezdeka]

Hey @shytikov,

so we have the same intention ;-)
I'm currently reading (and finishing) my GIT book. I had some gaps regarding the GIT internal Tree and Blob entries.

Please let me know when you start implementing.
I hope I have time to implement a (failing) test within the next few days.

Some very first thoughts about the API:

• Parameter Commit startCommit, defines where to start the history walking
• Parameter string filePath, defines for which file we will search for
• Parameter int maxCommits, defines when to stop history walking
• Result: A list of (affected) Commits, maximum legth of the resulting list is maxCommits

Still missing: A good name for the method name...

[shytikov]

@Flonix, @nulltoken

I've spent evening analyzing the code (it was marvelous time, it really was!) and come up with following questions to you:

• To do everything right, we need to implement this on C level an commit to libgit2 repository, but this will take time (and walking on thin ice of C). Is this ideologically right to make updates to libgit2sharp library only?
• Even if we decide to update libgit2sharp only there is a question, should we implement filtering on file name as part of commit filter class (used in QueryBy method of Commits collection) which is more close to libgit2 ideology, or put filtering by file name as property History or Commits (for example) of IndexEntry object, which will be more like object-oriented approach?

I'm confused a lot, since updating QueryBy method leads either to ugly code (implementation IEnumerable just passes calls to C backend and it will be hard to change its behavior to meet our needs), or IndexEntry updating will make libgit2sharp not so thin proxy to C backend...

Can you share your thought?

[shytikov]

Ahhh!!!

Somebody said, no matter how cool your code is, you will shame you wrote it six month later. It applies to messages in Issue Tracker too. Except the fact you feel shame much faster :)

We got RepositoryExtensions class!!! Perfect place for such code!

[fbezdeka]

@shytikov, @nulltoken

I think we should keep libgit2sharp as thin as possible.
But this does not exclude that we have to update/modify libgit2sharp as well...

I'm not sure if libgit2 has already some kind of history walking support. I'm not yet very familar with the code of libgit2.
So I have to take a look at it...

[shytikov]

@Flonix, it has revison walking api allowing you to limit your commits collection by date, branch, tag and maybe something else. But not file name.

As I get from @nulltoken answer, it's OK, to 'pre-limit' your commit selection by revison walking and then search in this collection with Linq for example.

At the moment I don't think I can come up with C code limiting commits selection by file name (need spent some time on libgit2 hacking), but it's easy to add new method ViewHistory in RepositoryExtensions class.

Is this approach libgit2sharp way?

[shytikov]

@Flonix, please take a look on the first draft in this gist

The work is still in progress, since it does not matches file if it was renamed and modified in the same commit. And ti does not count number of modifications.

[fbezdeka]

@shytikov,

some very simple thoughts after a very short look at your code:

• Looks good
• To speed up and not walking all the (maybe very long) history you may limit the maximum commits in the result

(If there are more then n commits you may start a further search at the last commit in the result, so you do not have to walk through the already found commits...)

Question 1: You are walking thorugh the all commits, yes, but are they ordered?

Question 2: Not sure what about merges...
This depends on question 1...
If they are ordered... Which commit-parent will be taken to continue the search?
If they are not ordered... We may have to order them ;-)

[shytikov]

@Flonix, thanks!

A lot of open questions remains and they are mostly facing C backend...

To speed up the code two things need to be done:

• Add maxCommits variable;
• Stop iterating if either matching SHA or Path not found (the file is not present in the repository — will be added in next commit);

Regarding ordering commits... This is easily can be done by using following syntax:

 foreach (Commit c in repository.Commits.QueryBy(filter))
 { ... }

But this means we need to pass this filter to the method. And as I see an libgit2sharp design it would be better to implement this as a part of the Filter. Add two more fields to this class: IndexEntry (object holding both file's SHA and Path) and MaxCommits to limit their number. And make results dependent of their values.

But to do it right we need to modify C code, because IQueryableCommitCollection is linked to native calls pretty tight.

Regarding merges I don't know... this is the thing definitely worth checking :)

[shytikov]

@Flonix, @nulltoken,

could you please advice me, how to skip merges while retrieving commits history for file. It seems, the SHA of file changes despite fact it was not changed actually. Is there any common approach on this? I don't want to run binary comparison for file blobs...

[shytikov]

@Flonix, one 'nice' surprise this morning: the code I wrote invalid for files stored in sub-folders :) The Tree object holds files from root-folder only. For browsing other folders we need to analyze collection of trees attached to current tree! 🆒

[fbezdeka]

@shytikov

Yes, that is true. There is one tree for each (sub)directory.
I looked into the libgit2 C code yesterday evening. There is a kind of revision walking implemented.
I will look to it closer on the weekend.

[shytikov]

@Flonix, I'm also hacking around. For now what I found that it's possible to hide a pack of commits from being returned to user. But before that the system should determine list of commits where given file was not changed, and pass this information as argument.

Looking forward to hearing from you on Monday.