oxidize lilgit?

[abathur]

I maintain a small git status prompt plugin (https://github.com/abathur/lilgit) that uses a mix of git2 and shelling out for diff commands that are much faster via the git CLI.

I needed a distraction this weekend so I (finally) took a look at switching it to gitoxide:

abathur/lilgit@fec61d6#diff-0d38d1e1503421fbfddac213c09243d5eec6a47822631b22458c804c7005694a

This went pretty well, though it did leave me wondering:

• if I took the most-direct route on some of these
• whether you think shelling out is also the best choice for the diffs

[Byron]

Thanks for sharing!

I left a few comments on the commit you linked.

• if I took the most-direct route on some of these

Yes, I really liked what I saw and how the head API shines in comparison to git2. The upstream() method in git2 is really missing in gitoxide though, and it shows. That definitely has to change but I don't know when it will.

• whether you think shelling out is also the best choice for the diffs

At the moment this is the best choice even for gitoxide. However, gix will be significantly faster in the case that something is dirty as you will be able to make it stop once the first change or untracked file has been found. Also, all the involved diffs will be run in parallel. I still have to think about the implementation for this, but I will definitely keep you case in mind which isn't interested in the details, just in the binary yes or no answer for 'is it dirty?'. Even in the case where there is no change and all the work has to be done, I believe that gix can be faster than git due to its parallelism.

[abathur]

Thanks for the notes.

• Yes--I liked the head API here. Much cleaner. I was much less confident around (and took a bit of fumbling to figure out) how to ~replace upstream().
• Thanks for confirming that it's still early to go trying to make the diff work.

I don't expect one since lilgit is tiny compared to most projects you've made ~tracking issues for, but I figure it doesn't hurt to ask since there isn't an existing issue for at least the upstream() method question :)

[Byron]

That's a great idea, and I'd love to track this feature by means of lilgit :).

I can even see myself implement it soonish, as it shouldn't be too hard while it carries a lot of utility.

I don't expect once since lilgit is tiny compared to most projects you've made ~tracking issues for, [..]

It's true that when it's left to me I choose candidates based on 'reach', but having a smaller project with a super friendly and responsive author who can provide feedback on the APIs, that's just as good for gitoxide. So, thanks for trying gitoxide and providing the feedback it needs to make it 'the best possible version of itself' :D.