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 :).