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

111–120 of 120 posts

Re: Steve's Jujutsu Tutorial

#111

Post by stouset »

stavros wrote: post #95

This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapsho…

Changes are a stable ID for a single conceptual modification to the repo. They are backed by—at least right now—a regular git commit with a content hash.

As you iterate on one change, new underlying git commits are made to snapshot the latest state of the current change being edited. The change ID remains stable though the backing commit ID varies as the change’s contents are modified.

You can always revert a change back to a previous backing commit.

This has a few cool implications.

First, you never have uncommitted changes. You are always editing a “current” change with an ID that is regularly persisting your work (either every time you run a jj command or with a filesystem event monitor).

Second, you’re never “on” a named branch: you’re only ever “on” a change and named branches are just mutable pointers to change IDs. This is awesome for a long-lived linear bit of work that needs to be merged in piecemeal. In git you’d need multiple branches based on one another and nothing tracks the relationship between them. Updating earlier work is painful. With jj, it’s all just one linear branch with some changes having names. If you need to edit an earlier change or insert new ones, you just… do that.

Re: Steve's Jujutsu Tutorial

#112

Post by stavros »

stouset wrote: post #111
stavros wrote: post #95

This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapsho…

Changes are a stable ID for a single conceptual modification to the repo. They are backed by—at least right now—a regular git commit with a content hash. As you iterate on one change, new underlying git commits are made to snapshot the latest state of the current change being edited. The change ID remains stable though the backing commit ID varies as the change’s contents are modified. You can always revert a change…

Thank you, this clarifies things. And the changes aren't shown to git clients/GitHub? They just see a bunch of commits?

I should probably use jj at this stage and figure all this out for myself, rather than just read about it. Thank you!

Re: Steve's Jujutsu Tutorial

#113

Post by stouset »

stavros wrote: post #112
stouset wrote: post #111

Earlier quoted context omitted.

Changes are a stable ID for a single conceptual modification to the repo. They are backed by—at least right now—a regular git commit with a content hash. As you iterate on one change, new underlying git commits are made to snapshot the latest state of the current change being edited. The change ID remains stable though the backing commit ID varies as the change’s contents are modified. You can always revert a change…

Thank you, this clarifies things. And the changes aren't shown to git clients/GitHub? They just see a bunch of commits? I should probably use jj at this stage and figure all this out for myself, rather than just read about it. Thank you!

They (and you, unless you go digging) only see the latest commit associated with each change.

The older ones are there in your local repo but they’re invisible unless you need to look through the “obsolete log” to find earlier iterations of changes. This is similar to (and built on, essentially) git’s reflog that holds on to commits that are no longer in active use.

There’s also an “operations log” that, instead of tracking history of individual changes, tracks history of the entire repo. So if you reorder or drop changes, you can always undo those operations.

Re: Steve's Jujutsu Tutorial

#114

Post by spott »

aos wrote: post #16

I’ve started to use jj much more often (and actually used this tutorial to get me started!). I do wish its interaction with Nix flakes is less annoying though, but that’s not the fault jj.

How is it annoying?

Re: Steve's Jujutsu Tutorial

#115

Post by hinkley »

sheremetyev wrote: post #52
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…

for me important argument in favour of JJ over Sapling was "first-class conflicts" - JJ stores conflicts in the history and allows you to resolve them later, while Sapling forces you to resolve conflicts at the point when they happen https://martinvonz.github.io/jj/latest/sapling-comparison/

If first class resolution is done right, then instead of project generators we can just create sample projects that people fork, and when you make breaking changes or add new startup config to the project, you update the sample project(s) and people can pull the updates. Once you resolve the conflicts you’re done until the next change, at which point your repo remembers how the last conflict was resolved, and doesn’t ask you to redo it.

This is why jj is on my todo list. I’m not calling it jujutsu no matter how much someone pays me though.

Re: Steve's Jujutsu Tutorial

#116

Post by softjobs »

chronial wrote: post #33
kettleballroll wrote: post #23

Earlier quoted context omitted.

Same. I miss the old times when people tried naming their projects sensibly. I mean, we're constantly telling ourselves how variable and function names should speak for themselves, but then we name our projects using random, completely non-descript names. It's a annoying.

Which old times are you referring to / what are "sensible" names? I thought about it and I don't know what a better name would be. Off the top of my Head, I know Perforce, BitWarden, Subversion, fossil and git. And then the abbreviations CVS, RCS and SVN. Do any of these qualify as a descriptive name?

You probably mean BitKeeper. BitWarden is a password / secrets manager.

Re: Steve's Jujutsu Tutorial

#117

Post by atoav »

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…

To me at least it makes so much more sense to be like:

1. I am going to work on $X

2. autocommit

3. My work on $X is done

rather than

1. I make changes

2. I am done making changes

3. Now I have to describe what I changed and how

Maybe this is just me, but with git it is at times hard at times to hit the right balance in terms of commit granularity — and for my flow planning forward ("I am gonna do $X") rather than describing what I did ("I did $X") seems more.. focused?

Re: Steve's Jujutsu Tutorial

#118

Post by sunshowers »

38 wrote: post #12
steveklabnik wrote: post #11

Earlier quoted context omitted.

https://steveklabnik.github.io/jujutsu-tutorial/hello-world/... > The very first character at the top left is an @. @ is a special name for "whichever commit the working copy reflects." At first I kind of thought about it like HEAD in git, but that's not correct: HEAD is the most recent commit, but @ represents the working copy, which may be "dirty" from git's point of view. This is our first glimpse into the power o…

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

Please try out Jujutsu.

Re: Steve's Jujutsu Tutorial

#119

Post by jFriedensreich »

forks wrote: post #106
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…

Could you say more about how/why "graphite does not work"?

graphite only works with graphite tooling. you cannot just use sapling or jj to create a pr on github and then use graphites review tool, even though this should work in theory, but they block this somewhere in the pipeline.

Re: Steve's Jujutsu Tutorial

#120

Post by yencabulator »

gcarvalho wrote: post #88
riwsky wrote: post #70

Earlier quoted context omitted.

If it helps, they actually named it after their desired CLI abbreviation: > The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".

And the martial art is jiu-jitsu, not jujutsu. Similar sounding but definitely not “named after”.

No it's not, but so far the Brazilians are still sticking with the incorrect ~1908 way of writing it.

Standard Japanese pronunciation for "jutsu" does not contain an i, and it's also judo not "jiu-do" that the old system would have called for.

https://en.wikipedia.org/wiki/Jujutsu#Etymology

Post reply on HN