Add LogWalkerWithoutFilter, using gitoxide

[cruessler]

This PR is split from #2269. It is focuces on the single use case of walking the log when there is no filter.

The current LogWalker implementation accepts a filter of type Option<SharedCommitFilterFn> with type SharedCommitFilterFn = Arc<Box<dyn Fn(&Repository, &CommitId) -> Result<bool> + Send + Sync>. As you can see, this function takes a git2::Repository as an option. Unfortunately, this does not work with gix.

When using gitx to walk the log, we open the repository through gix::open which returns a gix::Repository, a struct that is incompatible with git2::Repository. In order to make filtering work with gix, we would have to rewrite quite a bit of code in commit_filter. In particular, we would have to make get_commit_diff work with gix::Repository.

In order to limit this PR’s impact as well as the implementation effort, I thought it might be better to postpone this work and focus on the case of searching without a filter first.

It changes the following:

• It adds LogWalkerWithoutFilter, capable of walking the log using gix.

I followed the checklist:

• I added unittests
• I ran make check without errors
• I tested the overall application
• I added an appropriate item to the changelog

[extrawurst]

seems like gix introduces two different version dependencies on hashbrowns 🙈

can you investigate if this can be removed by disabling features of gix, I see it seems to be related to diffing which I think for our use case should not be needed

[extrawurst]

@cruessler one other solution if not ideal is to pass a git2::Repo AND the gix::Repo into the logwalker to keep the interface and use the one for walking and the other for filtering?

[cruessler]

@cruessler one other solution if not ideal is to pass a git2::Repo AND the gix::Repo into the logwalker to keep the interface and use the one for walking and the other for filtering?

@extrawurst I considered this option, but I thought it might be better not to mix both because I didn’t know whether either of them expected to have exclusive access to the .git directory. I wouldn’t say it’s likely, but I can at least imagine there might be subtle bugs when trying to access it using two different libraries. What do you think?

[Byron]

It's very exciting to see this work happening in gitui. Part of me thinks it's better to wait, particularly with the diffing, until there are nicer APIs for that, but that seems to be done now.

Regarding the hashbrown duplication, it seems like imara-diff needs an update. A PR there should be fine, and I'd expect Pascal to be very responsive as well or lets me help with maintenance if needed.

I wouldn’t say it’s likely, but I can at least imagine there might be subtle bugs when trying to access it using two different libraries. What do you think?

There won't be any issues. Not even concurrent writes can shake a Git repository if every implementation uses lock-files correctly, or just writes to the object store.
However, the amount of required system resources might double, i.e. double the open file handles if both are truly used concurrently. On the bright side, once the last clone of a gix::Repository goes out of scope, all system resources will be released with it.

Doing traversal with gix seems like a good starting point, even though one has to be careful to assure that the traversal is truly the same. Recently, there was the addition of a traversal mode that ought to be the same as the one used by git log, in case that's what you need. However, it's not yet wired up and currently only available in plumbing.

I hope that assorted knowledge helps in some way :).

[cruessler]

@extrawurst Using default-features = false and features = ["revision", "max-performance"], the dependency issues can be solved.

@Byron Thanks for the context, that’s very much appreciated! :-) There is already a PR open for updating hashbrown in imara-diff: pascalkuthe/imara-diff#6. It seems to be out of date, though. I can open a new one or we can ping the author of the existing one to update if you think that‘s a good idea.

[Byron]

Thanks for checking and linking the imara-diff PR - as it's already pretty old, I have reached out to Pascal to see if I can help with this, and will let you know of the outcome once I got a reply (something I'd expect within 24 hours or so).

[cruessler]

I just compared binary sizes for the release build between this PR and current master. On Windows, this change increases binary size by about 12 %, on Linux and Mac by around 8 %.

Detailed numbers

## Binary sizes on the PR

https://github.com/extrawurst/gitui/actions/runs/9742727520

ubuntu-latest
-rwxr-xr-x 2 runner docker 14579096 Jul 1 10:46 ./target/release/gitui

macos-latest
-rwxr-xr-x 1 runner staff 10718584 Jul 1 10:45 ./target/release/gitui

windows-latest
Mode LastWriteTime Length Name

---

-a--- 7/1/2024 10:46 AM 7464960 gitui.exe

-rwxr-xr-x 2 runner docker 14716232 Jul 1 10:41 ./target/x86_64-unknown-linux-musl/release/gitui
-rwxr-xr-x 2 runner docker 15375296 Jul 1 10:44 ./target/aarch64-unknown-linux-gnu/release/gitui
-rwxr-xr-x 1 runner staff 11356056 Jul 1 10:43 ./target/x86_64-apple-darwin/release/gitui

Binary sizes on master

https://github.com/extrawurst/gitui/actions/runs/9787466979

ubuntu-latest
-rwxr-xr-x 2 runner docker 13550192 Jul 4 02:17 ./target/release/gitui

macos-latest
-rwxr-xr-x 1 runner staff 9923544 Jul 4 02:17 ./target/release/gitui

windows-latest
Mode LastWriteTime Length Name

---

-a--- 7/4/2024 2:20 AM 6657536 gitui.exe

-rwxr-xr-x 2 runner docker 13706160 Jul 4 02:17 ./target/x86_64-unknown-linux-musl/release/gitui
-rwxr-xr-x 2 runner docker 14206336 Jul 4 02:26 ./target/aarch64-unknown-linux-gnu/release/gitui
-rwxr-xr-x 1 runner staff 10490920 Jul 4 02:18 ./target/x86_64-apple-darwin/release/gitui

Comparison

14579096 / 13550192 = 1.075932798590603
10718584 / 9923544 = 1.08011653901066
7464960 / 6657536 = 1.1212797046835346

14716232 / 13706160 = 1.07369474747121
15375296 / 14206336 = 1.0822844116878554
11356056 / 10490920 = 1.0824652175405016

[extrawurst]

On Windows, this change increases binary size by about 12 %, on Linux and Mac by around 8 %.

I am happy to pay that price in the meantime. the endgoal of reaching independence from libgit2 is worth the cost