Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Steve's Jujutsu Tutorial

steveklabnik.github.io

Post reply on HN
Print view View original

71–80 of 120 posts

Re: Steve's Jujutsu Tutorial

#71

Post by stavros »

emmanueloga_ wrote: post #32
nixosbestos wrote: post #7

One of my favorite people talking about my single favorite tool of the past 3+ years. Up there with (above, really) zellij and helix for changing my daily life.

Helix, the editor? How would you pitch it? Zellij looks powerful but also a bit too complex, following the "kitchen sink" school of design :-). No biggie but its name is too close to IntelliJ imho. What kind of workflow do you use with it? I used tmux a bit back in the day, but these days I feel like good old tabs and app windows cover my needs. When I want to multiplex processes in a single window, I reach for Overm…

I don't know what you find complex about Zellij, as I haven't used it extensively, but the few times I've used it, the UI was eminently self-describing, I managed to do everything I've needed to do within a minute of first launching it.

Is there more advanced stuff that's more complex that I just haven't seen?

Re: Steve's Jujutsu Tutorial

#72

Post by forrestthewoods »

I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta.

I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho.

I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won instead, alas.

My dream VCS system would have a virtual file system, copy-on-write storage, and a system wide blob cache. The goal being to allow open source repos to commit *ALL* their dependencies, up to and including toolchains in many cases.

Re: Steve's Jujutsu Tutorial

#73

Post by steveklabnik »

Kinrany wrote: post #69
steveklabnik wrote: post #56

Earlier quoted context omitted.

For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in res…

The holy grail of a stacked diff workflow would be making multiple Github PRs each made against the previous branch instead of trunk, and then updating the branch that's closest to trunk and rebasing all of the children PRs without having to force push into any of them. Git and Github do not support this workflow directly, and this creates space for all the other tools. Jujutsu comes close to supporting this workflow…

The https://github.com/sunshowers/spr fork supports jj :)

Re: Steve's Jujutsu Tutorial

#74

Post by aseipp »

jFriedensreich wrote: post #46

I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI c…

Gerrit, as I like to say, has a user interface that only a mother could love. But ultimately it's a very productive tool, so I just got over it. I even wrote some integration between jj and gerrit, making submitting stacks very easy and smooth.

IMO, Gerrit is the best currently available option by a large margin, notwithstanding its quirks.

Re: Steve's Jujutsu Tutorial

#75

Post by aseipp »

conaclos wrote: post #48
klauserc wrote: post #30

Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration. The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners). The auto committing behavior is a bit we…

> The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?

It's a bit of a magic trick. A "snapshot" is taken any time a command is run, and it happens implicitly before any actual algorithms or code for a given command is run (massively simplifying the internal design), so for all intents and purposes it's "automatic" from the user interface e.g. even checking repo status or otherwise small operations will cause a snapshot.

But you can integrate with https://github.com/facebook/watchman/ in order to have a truly daemon-ified option where any filesystem write will cause a snapshot to be taken.

Re: Steve's Jujutsu Tutorial

#76

Post by aseipp »

forrestthewoods wrote: post #72

I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta. I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho. I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won i…

I used Sapling for many months before switching to JJ. In my mind -- and I'm insanely biased as I am a JJ developer at this point -- they are both leagues ahead of Git, but I think JJ's Git interop, conflict handling, and general UX make it much more powerful and general than Sapling. Conflict handling alone is leagues better. (Martin worked on version control for a long time, and JJ is a tool that can only be created by someone with deep expertise in the domain, which I think shows itself over and over again in its use.)

If you are already using Sapling then at least trying it should be fairly easy and familiar. You could also write a JJ backend for Mononoke and EdenFS if you wanted and then use it at work ;) You wouldn't be the first JJ user from Meta, actually...

We do have plans to explore server-side designs with virtual filesystems, chunked storage, etc. There's nothing concrete yet.

(Another benefit is that JJ is much easier to write patches and contribute to due to being a relatively new, small Rust project, whereas Sapling is much more developed but much bigger and harder to get into, I think.)

Re: Steve's Jujutsu Tutorial

#77

Post by aseipp »

38 wrote: post #28
steveklabnik wrote: post #9

Earlier quoted context omitted.

I like jj because I like git's index so much. JJ lets me do what git's index does, but in a much more powerful way. What you do is, you treat @ like the index, and you work on @-. This is the "squash workflow" https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

OK but again thats awful, because @ IS A COMMIT, so you are only a "git push" away from accidentally pushing arbitrary garbage instead of proper changes

You are simply misinformed. `git push` always pushes the HEAD by default without question, but jj does not. @ is not special in any way, so it does not get special treatment from push. It will only push branches you tell it to or that have been amended/updated and are not immutable. jj also does not update any branch pointers (or "bookmarks" as we call them) unless you explicitly ask it to. You have to explicitly run `jj branch set ...` and then run `jj git push` to get the behavior you are describing, which is much more explicit.

Re: Steve's Jujutsu Tutorial

#78

Post by forrestthewoods »

aseipp wrote: post #76
forrestthewoods wrote: post #72

I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta. I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho. I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won i…

I used Sapling for many months before switching to JJ. In my mind -- and I'm insanely biased as I am a JJ developer at this point -- they are both leagues ahead of Git, but I think JJ's Git interop, conflict handling, and general UX make it much more powerful and general than Sapling. Conflict handling alone is leagues better. (Martin worked on version control for a long time, and JJ is a tool that can only be create…

JJ's conflict handling seems nice. Can't say that it's a big enough problem for me to qualify as a "major feature", but a seemingly nice improvement.

I'm not sure how I feel about JJ's "working copy commit". One of the great things about Meta VCS is that all commits are automatically backed up into the cloud. Which seems incompatible with the JJ model? Not sure. I think the D in DVCS is *wildly* overrated. 99.999% of projects are defacto centralized.

I'm #TeamMonoRepo 100% of the way. My background is gamedev and perforce. An industry which still uses Perforce because Git is poopy poop poop. The Git integration I want to see is the ability to easily sync a monorepo subfolder with an external GitHub repo. Syncing commits for internal projects that are open sourced requires a big ugly custom set of tooling. And I'd kind of like a way to do an "inner fork" within a monorepo if that makes sense.

If you're interested here's a pair of blog posts I wrote that have at least some of my thoughts on source control.

https://www.forrestthewoods.com/blog/dependencies-belong-in-... https://www.forrestthewoods.com/blog/using-zig-to-commit-too...

Re: Steve's Jujutsu Tutorial

#79

Post by rw_panic0_0 »

nixosbestos wrote: post #7

One of my favorite people talking about my single favorite tool of the past 3+ years. Up there with (above, really) zellij and helix for changing my daily life.

nice to see zellij+helix combo users out there. Helix been my fav editor for like a year already, zellij is also a daily driver, and now i'm learning jj :P

Re: Steve's Jujutsu Tutorial

#80

Post by swiftcoder »

steveklabnik wrote: post #56
swiftcoder wrote: post #39

> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked. I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.

For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in res…

Yeah, and I think it's also worth noting that by far the largest set of folks advocating for stacked diffs are not actually using git.

Meta runs a custom mercurial-compatible monorepo that was scaled up to handle thousands of commits per hour, and they have a culture of constant codebase-wide refactoring commits (i.e. the ongoing live migration of PHP -> Hack) - that rate of change causes problems that most GitHub projects have no reason to solve.

Post reply on HN