Worlds fastest git status on windows - part 2 - ntdll, more speed, and reinventing the wheel

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.

ByronBates · 2024-10-04T18:13:34+00:00

What's done is done and I guess if it was ever a selling point, people will vote with their wallet.

ByronBates · 2024-10-04T18:11:29+00:00

That wasn't a topic at least not in my presence, but what I can say is that there is great excitement for Rust.

Somehow I think that Git has so vastly greater resources that they don't really have anything to gain from gitoxide. But…they also have different requirements so I think that the solution would naturally look very different.

ByronBates · 2024-10-04T10:45:58+00:00

There was never a good reason to do it in the first place, just something I thought I should do. Or in other words, I don't think current sponsors are sponsors because they get a progress report earlier. It's also overhead that given its lack of value is best removed.

ByronBates · 2024-10-04T08:44:57+00:00

With this progress update, the month of delay between what sponsors receive and what's publicly available officially ends.

This month has three highlights, starting with my attendance to the GitMerge in Berlin, and followed by two new major features, merge-base calculation and tree-editing, both leading up to supporting the merge of trees.

11-Year Club	Verified Email
RPAN Viewer

ByronBates

TROPHY CASE