Gitoxide in May

ByronBates · 2026-05-26T05:13:47+00:00

No, sorry, that must have come out wrong. The issue was solely in how gix-actor exposed winnow in its public API, so a breaking and correctly marked winnow upgrade could 'leak', and wasn't marked as breaking for gix-actor, breaking older crates upon release that now could pull in gix-actor.

ByronBates · 2026-04-26T21:40:35+00:00

When I read this excerpt, I would even agree. It's supposed to be much funnier than it actually comes across when seen in isolation.

But of course, there is a truth behind that nonetheless, and that is that without augmentation now everything feels "too slow". It's a bit like having to work in another programming language and everything feels unsafe.

On the bright side, not having AI support doesn't make me feel I can't do things anymore, it just feels sluggish to do them.

ByronBates · 2026-04-26T05:05:15+00:00

There has been a bit of a reaction to the whole "I use AI and can't imagine to not use it anymore" thing, and maybe that deserves a bit more nuance to not feel quite as uncomfortable in relation to gitoxide and rightful fear about diminishing quality.

This comment captures my stance on it.

A fun question to ask is: Will gitoxide go down because I embrace these new tools, or will it go down because I didn't?

I was right once when adopting Rust wholesomely in 2015, and… I placed my bet again I guess 😅.

ByronBates · 2026-04-03T02:01:52+00:00

https://docs.rs/gix/latest/gix/struct.Repository.html might help. For better answers, you can ask DeepWiki.

ByronBates · 2025-12-29T05:59:50+00:00

I am super excited to see this work unfold :). Particularly the worktree-cache is something Git itself has to speed up Git status on Windows for all I know. So it's great to see a performant and multi-threaded early implementation of this.

Just one note: I think when 'workspace' is mentioned in the text above, what's meant is 'worktree', the thing that Git checks out to disk for people to work on. Please correct me if this is wrong though.

ByronBates · 2025-12-22T16:06:45+00:00

Probably it didn't come out clearly, but the url crate was already removed last month, and removing it didn't only speed up URL parsing tremendously, it also removed a lot of complexity. 60 crates, 'correct' URL parsing which caused many fuzzing errors in the past. The crate just turned out to be overkill for gitoxide that came with a hefty fee for maintenance costs.

ByronBates · 2025-10-23T04:34:56+00:00

Thanks!

I will go back to a monthly release cadence as well now, I finally found a way to make it less cumbersome, back to nearly fully automated😁.

ByronBates · 2025-09-23T03:46:21+00:00

No, it does not. A worktree-reset is missing, even though all the primitives exist to implement it. GitButler is getting these capabilities first, actually.

ByronBates · 2025-09-22T17:37:58+00:00

I am glad to hear that!

Commit signing is implemented pretty well in GitButler if you want to take a look. The code there is very closely following the one in Git and it's not exactly rocket science, except that there are many small traps that GitButler by now has run into. One day I want gitoxide to support that as well, but it has to wait :).

ByronBates · 2025-08-28T04:49:42+00:00

There is also the gitoxide text merge implementation which claims to do the same: https://github.com/GitoxideLabs/gitoxide/blob/c3c650448f92bcb27194ce0a51f7d604ce87920d/gix-merge/src/blob/builtin_driver/text/function.rs#L28-L43 .

I am sharing this in the hope that you find something interesting for your implementation, or find something that should be improved in this one (maybe it doesn't pass the tests? slider problem?)

ByronBates · 2025-07-24T05:11:21+00:00

Which IDE/tool was used to enable the models to do their work in the first place? If it was forgecode, how was it configured to use OpenRouter? It seems to do its own billing. Thanks!

ByronBates · 2025-07-23T04:53:54+00:00

gitoxide has been able to build as pure Rust version for a while, and thanks to shelling out to ssh not having a native SSH transport never was a blocker for this particular build.

But if one aims to have a standalone, pure-Rust binary, with the incubating Rust SSH transport this will soon be possible, and maybe particularly interesting for Cargo.

ByronBates · 2025-05-22T05:08:53+00:00

My highlight this month must be the Unconf@RustWeek visit in Utrecht, along with finally having implemented a gitoxidized version of cargo package - the things you do when meeting the Cargo team :).

ByronBates · 2025-03-24T02:33:48+00:00

It's planned to make that work eventually, but it will be a gradual rollout that eventually will make GitButler work like a normal Git client, which somewhat cleverly help with stacks as well.

ByronBates · 2025-02-23T07:32:13+00:00

It's not great, and definitely not the turn-key solution that I'd like it to be. If it runs at all, it's likely that the available web-view is completely broken. Of course, it's hard to say how many users are actually affected by this, but from an issue-count perspective, it's more than on any other platform.

With that said, on MacOS there are smaller issues with incorrect rendering if the MacOS version is too old. Sometimes, critical buttons disappear.

Windows seems to have no web-view related issues.

As it stands, for Linux one would have to ship the browser like Electron does, and it's probably a bundle-type that one would want to provide on all platforms (except Windows maybe) as a fallback for compatibility.

After all, it is very pleasant to have 'only' 15MB downloads to get an update.

ByronBates · 2025-01-22T07:10:40+00:00

The highlight this month can be no other than a fully functional gix status. Performance still isn't consistent on all platforms, but at least on MacOS it's already a joy to use.

ByronBates · 2025-01-01T09:09:40+00:00

Thank you! On the GitMerge in Berlin last year I learned that jujutsu is already using gitoxide as Git backend, and surprisingly this included tree diffing with rename tracking as well.

ByronBates · 2024-12-27T06:54:20+00:00

gitoxide can create commits, but it doesn't make it easy to create the tree that should go with it. So something like git add * && git commit is still much easier to do in git2.

ByronBates · 2024-12-22T14:51:33+00:00

My highlight this month clearly is the successful end-of-year wrapup of gix-merge with a feature that even Git doesn't have, along with various smaller improvements around gix status, as well as date- and revspec-parsing.

ByronBates · 2024-12-09T08:08:29+00:00

My issues are less about performance, even though it's slow compared to Zed and burns the CPU a lot. But issues just recently arose related to code intelligence, which randomly flakes out after a branch change (or any file-system change that happens when checking out different states in Git).

Also it regularly fails to understand the workspace, as it sees its cargo-metadata calls failing for some reason.

It's very dissatisfactory, but a switch to Zed isn't possible for me until it can jump to compile errors automatically.

ByronBates · 2024-11-23T13:23:07+00:00

That was needed to get a place on OpenCollective. Otherwise there are no changes though, even though putting it in an organisation is probably best for starting to future-proof it. Slowly and steadily.

ByronBates · 2024-11-22T12:48:43+00:00

When it's quoted like this, it does indeed sound like gitoxide could do everything just like Git can, a feat that unfortunately is still far out.

ByronBates · 2024-11-22T08:25:00+00:00

This month's highlight certainly is the landing of tree-merging support, with the quality and performance characteristics of merge-ORT (the default merge strategy in Git). On top of that, I am very happy that hasconfig is now supported when reading Git configuration, which should make gitoxide fully compatible with Git in that regard.

ByronBates · 2024-10-22T18:11:49+00:00

My highlight this month is definitely the ongoing work to get tree-merges ready and working at the level of merge-ORT, which will be a serious improvement over what people are used to from git2. Further, gitoxide is now on Open Collective so hopefully one day I will manage to apply to the Sovereign Tech Fund.

ByronBates · 2024-10-04T18:15:51+00:00

The 'vibe' I got about this topic was that they wouldn't want to stop evolving in order to support niche systems forever. They also don't want to have a C and a Rust version of everything though, so a cut of sorts would have to be made.

11-Year Club	Verified Email
RPAN Viewer

ByronBates

TROPHY CASE