feat: resolve git file attrs

[tisonkun]

• This closes Support for different years #147.
• This closes Add file create year and file modified year #114.

This is somehow expensive. I test against OpenDAL which has ~1000 files to format and 2600+ commits to analyze, it takes about 4 seconds to finish. So by default, I set the config value to disable.

[tisonkun]

These changes seem no help. Because we still find object for tree? And iter over all the changes on every location.

[tisonkun]

For e576dad

[Byron]

Thanks for the invite - I just had time for a glimpse.

[Byron]

Here you want to use gix::path::from_bstr(change.location), never use String when anything path related is happening as they can't represent everything that's possible on the filesystem.

[tisonkun]

Thanks for your advice. I try to write:

                let filepath = gix::path::from_bstring(change.location);
                match attrs.entry(filepath) {

But the filepath is something like "fmt/tests/tests.rs" which cannot match the selections "/Users/tison/Brittani/hawkeye-native/fmt/tests/tests.rs" on the later get.

[tisonkun]

Calling filepath.canonicalize() here will result in IO error No such file or directory. I guess it's because no base dir specified.

Perhaps I can use still workdir.join(filepath)?

[Byron]

Git tracks paths relative to the repository root, hence one will have to join them with the worktree root before using them on the filesystem.

[tisonkun]

Yeah. Thanks for your information.

This changes iteration currently take about 4 seconds on a repo having ~1300 files and ~2600 commits.

I wonder what is the major performance factor and whether we can improve it (e.g., does git work well in such situations?).

It seems most cycles are used to parse the tree data which we can do nothing to improve.

BTW, gitoxide already out performance than git command as:

for i in $(git ls-files); do git --no-pager log --follow --format=%ad -- $i > /dev/null; done

takes 1 minute and 5 seconds to finish.

[Byron]

It's hard to get an apples-apples comparison since Git definitely does way more work here as it goes through the whole history once per file, but the Rust code only has to go through once. From that point of view, Git's performance is impressive.

I wonder what is the major performance factor and whether we can improve it (e.g., does git work well in such situations?).

Object-access performance is critical, and there are some variables regarding caches that can be set. They can improve performance by a couple of percent, but it's nothing more significant.
But wait, in this line the max-performance feature can be added, it should be noticable.