4 ms·

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 replac

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.

steveklabnik 2y ago
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/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/ https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...
- AceJohnny2 2y ago
  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 https://git-scm.com/docs/git-interpret-trailers
  - steveklabnik 2y ago
    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.
    - bananapub 2y ago
      ~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~ ignore, misread the above
      - steveklabnik 2y ago
        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)
        bananapub 2y ago
        ah, I'm sorry, I misread your comment (and should have mentioned the cherry-pick thing anyway).
        steveklabnik 2y ago
        It’s all good!
  - aseipp 2y ago
    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.
    - AceJohnny2 2y ago
      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)?
      - aseipp 2y ago
        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/5dc9da3c2b8f502b4f93ab336b3cd16288e3c9e0/lib/src/simple_backend.rs#L154 https://github.com/jj-vcs/jj/blob/5dc9da3c2b8f502b4f93ab336b...
esafak 2y ago
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?
- steveklabnik 2y ago
  (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...
- renerick 2y ago
  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.
- Zambyte 2y ago
  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.
pmarreck 2y ago
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)
filmgirlcw 2y ago
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!
deleted 2y ago
[deleted]

steveklabnik 2y ago

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/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/ https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

AceJohnny2 2y ago
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 https://git-scm.com/docs/git-interpret-trailers
- steveklabnik 2y ago
  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.
  - bananapub 2y ago
    ~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~ ignore, misread the above
    - steveklabnik 2y ago
      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)
      - bananapub 2y ago
        ah, I'm sorry, I misread your comment (and should have mentioned the cherry-pick thing anyway).
        steveklabnik 2y ago
        It’s all good!
- aseipp 2y ago
  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.
  - AceJohnny2 2y ago
    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)?
    - aseipp 2y ago
      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/5dc9da3c2b8f502b4f93ab336b3cd16288e3c9e0/lib/src/simple_backend.rs#L154 https://github.com/jj-vcs/jj/blob/5dc9da3c2b8f502b4f93ab336b...

esafak 2y ago

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?

steveklabnik 2y ago
(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...
renerick 2y ago
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.
Zambyte 2y ago
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.

pmarreck 2y ago

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)

filmgirlcw 2y ago

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!

deleted 2y ago

[deleted]