Hacker News Reader

Comment by Zambyte | Hacker News Reader

Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate.

Once you transition your mental model from working branch with a staging area to working revision that is continuously tracking changes, it's very hard to want to go back.

View on HN

GitButler and jj are very friendly with each other, as projects, and are even teaming up with Gerrit to collaborate on the change-id concept, and maybe even have it upstreamed someday: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

This is exciting, convergence is always good, but I'm confused about the value of putting the tracking information in a git commit header as opposed to a git trailer [1] where it currently lives.

In both cases, it's just metadata that tooling can extract.

Edit: then again, I've dealt with user error with the fragile semantics of trailers, so perhaps a header is just more robust?

[1] https://git-scm.com/docs/git-interpret-trailers

I'm not an expert on this corner of git, but a guess: trailer keys are not unique, that is

  Signed-off-by: Alice <alice@example.com>
  Signed-off-by: Bob <bob@example.com>

is totally fine, but

  Change-id: wwyzlyyp
  Change-id: sopnqzkx

is not.

I've also heard of issues with people copy/pasting commit messages and including bits of trailers they shouldn't have, I believe.

~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~

ignore, misread the above

That's a downside of using headers, not a reason for using them. If upstream git changes to help this, it would involve having those preserve the headers. (though cherry-pick has good arguments of preserving vs generating a new one)

ah, I'm sorry, I misread your comment (and should have mentioned the cherry-pick thing anyway).

It’s all good!

Mostly because it is jarring for users that want to interact with tools which require these footers -- and the setups to apply them, like Gerrit's change-id script -- are often annoying, for example supporting Windows users but without needing stuff like bash. Now, I wrote the prototype integration between Gerrit and Jujutsu (which is not mainline, but people use it) and it applies Change-Id trailers automatically to your commit messages, for any commits you send out. It's not the worst thing in the world and it is a little fiddly bit of code.

But ignore all that: the actual _outcome_ we want is that it is just really nice to run 'jj gerrit send' and not think about anything else, and that you can pull changes back in (TBD) just as easily. I was not ever going to be happy with some solution that was like, "Do some weird git push to a special remote after you fix up all your commits or add some script to do it." That's what people do now, and it's not good enough. People hate that shit and rail at you about it. They will make a million reasons up why they hate it; it doesn't matter though. It should work out of the box and do what you expect. The current design does that now, and moving to use change-id headers will make that functionality more seamless for our users, easier to implement for us, and hopefully it will be useful to others, as well.

In the grand scheme it's a small detail, I guess. But small details matter to us.

Thanks for the explanation!

While you're around, do you know why Jujutsu created its own change-id format (the reverse hex), rather than use hashes (like Git & Gerrit)?

I don't know if it's the only or original reason, but one nice consequence of the reverse hex choice is that it means change IDs and commit IDs have completely different alphabets ('0-9a-f' versus 'z-k'), so you can never have an ambiguous overlap between the two.

Jujutsu mostly doesn't care about the real "format" of a ChangeId, though. It's "really" just any arbitrary Vec<u8> and the backend itself has to define in some way and describe a little bit; the example backend has a 64-byte change ID, for example.[1] To the extent the reverse hex format matters it's mostly used in the template language for rendering things to the user. But you could also extend that with other render methods too.

[1] https://github.com/jj-vcs/jj/blob/5dc9da3c2b8f502b4f93ab336b...

Yes, it was to avoid ambiguity between the two kinds of IDs. See https://github.com/jj-vcs/jj/pull/1238 (see the individual commits).

Interesting, that was just a few short months before I showed up. :)

jj is fantastic and I love it so much. Takes the best things I liked about hg but applies it to a version control system people actually use!

Can second this. Beware that your old git habits may die hard though. (It's nice that it uses Git as its storage backend, for now, though)

How long did it take you to become proficient? I assume your organization uses git and you use jujitsu locally, as a layer on top?

(not your parent)

> How long did it take you to become proficient?

As with anything, it varies: I've heard some folks say "a few hours" and I've had friends who have bounced off two or three times before it clicks.

Personally, I did some reading about it, didn't really stick. One Saturday morning I woke up early and decided to give it a real try, and I was mostly good by the end of the day, swore of git entirely a week later.

> I assume the organization uses git and you use jujitsu locally, as a layer on top?

This is basically 100% of usage outside of Google, yeah. The git backend is the only open source one I'm aware of. Eventually that will change...

It's really not that long. Once you figure out that

1. jj operates on revisions. Changes to revisions are tracked automatically whenever you run jj CLI

2. revisions are mutable and created before starting working on a change (unlike immutable commits, created after you are done)

3. you are not working on a "working directory" that has to be "commited", you are just editing the latest revision

everything just clicks and feels very natural and gets out of the way. Want to create a new revision, whether it's merge, a new branch, or even insert a revision between some other revisions? That's jj new. Want to move/reorder revisions? That's jj rebase. Want to squash or split revisions? That's jj squash and jj split respectively. A much more user-friendly conflict resolution workflow is a really nice bonus (although, given that jj does rebasing automatically, it's more of a requirement)

One notably different workflow difference, is absence of branches in the git sense and getting used to mainly referring individual revisions, but after understanding things above, such workflow makes perfect sense.

I don't really remember exactly how long until I felt particularly comfortable with it. Probably on the order of days? I have never really used any other VCS besides vanilla git before, so I didn't really have any mental model of how different VCSs could be different. The whole working revision vs working branch + staging area was the biggest hurdle for me to overcome, and then it was off to the races.

And yes, I use jj locally with remote git repos.

Not parent, but for me it was a couple hours of reading (jj docs and steve's tutorial), another couple hours playing around with a test repo, then a couple weeks using it in place of git on actual projects where I was a bit slower. After that it's been all net positive.

Been using it on top of git, collaborating with people via Github repos for ~11 mos now. I'm more efficient than I was in git, and it's a smoother experience. Every once and a while I'll hit something that I have to dig into, but the Discord is great for help. I don't ever want to go back to git.

And yes, jj on top of git in colocated repos (https://jj-vcs.github.io/jj/v0.27.0/git-compatibility/#co-lo...).

If you set explicit bookmark/branch names when pushing to git remotes, no one can tell you use jj.

> Every once and a while…

The expression is “every once in a while” :).

Oops :)

Reply on news.ycombinator.com