git-workshop VS jj

I have contradictory feelings regarding git. For more than ten years, I was using it daily without really understanding the internals... and I was often confused and frustrated. After investing some time learning how the Directed Acyclic Graph works, suddenly everything made much more sense.

And, yes: it is good to learn the underlying fundamentals of the technology we are using. But, on the other hand, it denotes a rather poor abstraction from the UX point of view, imho.

Now, when I deliver git training, I start by explaining the DAG and how there is no magic, only git. By the way, the notes and exercises of the course are in my GitHub account[1], feel free to check it out if you think it can be useful.

[1] https://github.com/ciberado/git-workshop (https://ciberado.github.io/git-workshop/)

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

Sorry you had a bad time with jj!

> Google results were pretty scarce and unhelpful.

This is true, the Discord is very active and helpful though: https://discord.gg/bKWAbtpH Discord isn't for everyone, but you can get help quickly. You can also ask questions as GitHub Discussions: https://github.com/martinvonz/jj/discussions

> How do I access the results of the rebase and update my PR branch?

So, one small difference between jj and git is that jj's branches don't move. In the next jj release, "branches" will be renamed to "bookmarks" to kinda emphasize this difference, even though they're used for git interop. Additionally, there's some discussion about what making branches/bookmarks move like git branches move could mean, with an experimental setting to give that a try.

With all of that said, when you rebased, it shouldn't have changed where the head of your branch was pointed to, so you shouldn't have needed to actually move anything here. This is a side effect of the change/commit distinction: the branch points to a change, so when you rebase your stuff, the commits will change, but the change will not. That means all you needed to do was...

> How do I force push that branch?

`jj git push` will force push all of your changes.

> It feels like the documentation is in the same place that Git was in during the early days - I assumes you are deeply familiar with the idiomatic workflow.

I agree that the documentation isn't in a super awesome place yet, but I think the cause is kind of the opposite: there isn't really one idiomatic workflow, but instead a few common ones, and a hesitation to demand that a specific workflow is idiomatic.

That being said, I have an in-progress tutorial that I have been waiting for two recent changes to land (one being the branch -> bookmark rename, the other being a different rename (obslog -> evolog)), that is intended to land upstream once I'm done with it: https://steveklabnik.github.io/jujutsu-tutorial/

After that, if I can keep finding the energy, I'd love to keep improving the documentation, but I have a lot less FOSS energy than I used to, so we'll see.

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.

Here, we are working on change 'pzoqtwuv'. (@ means the working copy.) There are colors in the real CLI to make the differences more obvious, and to show you unique prefixes, so for example, you probably only need 'p' or 'pz' instead of 'pzoqtwuv' to uniquely identify the change. I'll use the full IDs since there's no syntax highlighting here.

We have two anonymous branches here. They have the change IDs of 'xrslwzvq' and 'yykpmnuq'. The log output shows the summary line of their messages, so we can see "create hello and goodbye functions" on one branch, and "add better documentation" on the other.

You don't need an additional branch name: the change ID is already there. If you want to add even more better documentation, 'jj new yykpmnuq' (or again, likely 'jj new yy' in practice) and you're off to the races. (jj new makes a new change off of the parent you specify.)

That's all there is to it. We already have the commit messages and IDs, giving an additional identifier doesn't help that much.

(And if you're in a larger repo with more outstanding branches, you can ask 'jj log' to show specific subsets of commits. It has a powerful DSL that lets you do so. For example, say you only want to see your commits, 'jj log -r 'mine()'' can do that for you.)

> Auto commit of saved files? How do I commit the things I want without leaving all sorts of junk I don’t wanna share in my history?

The simplest answer is "you put that stuff in your .gitignore and it never gets committed." That said, it is recognized that sometimes that is not possible or easy. See https://github.com/martinvonz/jj/issues/323 for the current discussion about how to maybe support alternatives here.

> I have no impression of how this makes anything easier.

My take on this is that jj has fewer but also more orthogonal concepts. Naming things is hard. I don't like to do it. Not needing to name branches is really nice, as I don't really lose anything by not naming them, and I no longer have to name them.

With regards to some other stuff, the "auto commit of saved files" really means that jj turns two of git's concepts, commits and the index, into one concept: commits. How is that easier? Well, I don't need to learn two sets of tools for dealing with the index vs a commit. For example, git has two kinds of resets: hard and soft. This is because git needs to have two sets of behaviors to deal with both concepts here, as git reset is about changing the index but maybe or maybe not the working tree. All of these distinctions don't matter in jj, because it's all just commits, so you use regular old tools on commits for them.

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/