Replace libgit2 with gitoxide

[o2sh]

Following #621, we wish to drop libgit2 and use gitoxide instead.

What's left:

• status index/worktree (without diffstats, and submodule support with 'is-dirty' granularity)
• status untracked + recurse untracked dirs
• write index back (even though we shouldn't do it unless it's lossless, should be discussed at least)

[Byron]

Also see the corresponding tracking ticket at gitoxide, showing which features are implemented already.

@o2sh Would you be OK if I contributed the most promising part related to traversing the commit-graph for a start? This would mean that build times increase due to building git2 and gitoxide (minimal, only the required crates at first). Otherwise we'd have to wait until all features are available, which is probably no more than a couple of months.

That said, I'd prefer to get started right away and am happy to see the transition through until completion.

[o2sh]

Sure, the commit-graph traversal is indeed the most crucial part.
Looking forward to see your contribution.

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Byron]

git status is going to happen soon and then the issue can be properly resolved.

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Byron]

I have updated the description to be more precise, and hope that at least one of these checkboxes can be ticked soon.

[spenserblack]

Thanks!

even though we shouldn't do it unless it's lossless, should be discussed at least

Well, I'm open to discussion 😆. Could you elaborate on this one, though? I'm not 100% sure what this task means, or when it would have been completed.

[Byron]

The index file has a lot of state in it which is used to accelerate certain git operations. If a git status is run, it might update some file-stat information of entries (rare), and in order to not redo that work (usually very little) one would have to write these changes back. But the way this is currently implemented, it will drop most index-extensions as writing them isn't implemented, only reading is. This will not break the index, but it might make some operations which rely on these now missing extensions to be slower. An example for this is the untracked files extension which git uses to learn about untracked files faster.

Thus I propose not to write the index back at all, so onefetch is truly read-only without unintended side-effects, no matter how rare or noticeable they might be.

[spenserblack]

Got it, makes sense!

Thus I propose not to write the index back at all, so onefetch is truly read-only without unintended side-effects, no matter how rare or noticeable they might be.

Yeah, I agree. Being read-only can also help with file permissions in the future.