freecad-build VS jj

yes, i built this to solve that problem: https://github.com/khimaros/freecad-build

We strongly considered Graphite as an alternative to Gerrit at my last job that I mentioned at the start of this post (which I am no longer at, actually) because it does look like an absolutely excellent product, I will admit. You should all be proud of a smart design and smart set of tools.

But there's a really really really really really really big problem. Me and the other main engineer on our team use a custom frontend to Git called Jujutsu[1] for all my development. Jujutsu is about 1000x better than Git. So that's nice.

But gt, the graphite client, is not open source. I have no idea how to make them work together. I have no idea how to extend Jujutsu to handle Graphite stacks, because I don't even think there's an API to handle any of this.

I even wrote a Gerrit integration for Jujutsu to handle this, and Gerrit + Jujutsu is absolutely a force to be reckoned with IMO, even if the UX isn't as nice as Graphite's.

Please! Make gt open source and make it possible for third parties to make and update stacks. This isn't just useful for jj but all kinds of automation that wants to contribute patches -- imagine tools like Google's internal "Code Review ML models" that might recommend you rename a variable based on context. They will suggest the fix for you or even apply it!

[1] https://github.com/martinvonz/jj

Honestly, that's less keystrokes than adding a shellAlias. If you aren't sold on using nix to manage your system's configuration, this seems overcomplicated. If you use nix, then you are already probably frustrated at keeping your nix configuration in sync with quick little optimizations you do on a regular basis. With nix, everything is source controlled. If you are a dotfiler, then you would still have to commit your changes. I guess that's true in my solution as well. The git add in my update is probably the most dubious element of this entire schrade. That is unless, you are using jj.

I completely missed the `` argument despite being the first thing documented under `jj log`. That's definitely the most critical feature out of my list, thank you for pointing that out!

Also, it's great to hear that you're willing to accept contributions for those features. If/when Jujutsu gains critical mass, I imagine that someone will end up contributing these features.

Regarding rename detection, it seems like that is actively being worked on, which is really encouraging! https://github.com/martinvonz/jj/pull/3574

martinvoz/jj: https://github.com/martinvonz/jj :

> Working-copy-as-a-commit: Changes to files are recorded automatically as normal commits, and amended on every subsequent change. This "snapshot" design simplifies the user-facing data model (commits are the only visible object), simplifies internal algorithms, and completely subsumes features like Git's stashes or the index/staging-area.

Change-Id likely(?) comes from https://github.com/martinvonz/jj, which is used internally at Google with the Piper forge. (I think, I am not a Googler, just a happy jj user)

IMO Open Source software communities are where folks like you can really thrive. They're much closer at something like a meritocracy than traditional workplaces.

> I want to make the next-gen version control system

While you certainly could invent one yourself, you could consider contributing to popular ones like git/mercurial. It'd help teach you both the positive and the negative aspects of their design choices. Also you could consider learning from newer approaches like Jujutsu [1] or Pijul [2] on your way to designing the next-gen system. Good luck!

[1] https://github.com/martinvonz/jj

[2] https://pijul.org/