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

Jujutsu VCS: Introduction and patterns

kubamartin.com

Post reply on HN
Print view View original

51–60 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#51

Post by christophilus »

cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

If you switch between branches a lot, it's a game changer. I look at it as just git with a sane CLI.

Re: Jujutsu VCS: Introduction and patterns

#52

Post by sfink »

I've been using jj for a month, coming from mercurial. I have settled into a usage pattern slightly different than the article describes, so that all of those `jj edit` commands made me a little itchy. I prefer to nearly always use a separate @ commit to hold any changes I make. The mental model is that there's a graph of commits, and then @ is an auto-updated commit to hold any changes I make in an editor or whatever. Actually modifying anything in the core graph is then a conscious decision, and I might decide to update a commit with my changes (`jj squash` or `jj squash --into X`) or make the changes into a commit of their own (`jj describe` if I haven't already, followed by `jj new` to return to the stable state of having an @ commit for collecting changes).

The reason why I don't like using `jj edit` on something in the graph is that every change I make is conceptually applied immediately to all descendants. It's sort of like plucking a commit out of the graph (the commit you're editing), entering a mode where you can only modify that commit and don't have the option to use the changes in a different way (as in, squash some of them to some other commit or make a new branch or whatever).

It makes jj modal, and one of the things I most appreciate about jj is that it is not modal, you don't have a separate staging area or stash or anything, it's always in the same consistent state where you can do the same set of things.

Also, having a separate commit makes it easy to see how you've modified things, rather than only being able to see the sum total of the original commit contents plus your recent modifications. (It does make it a little harder to see that sum: `jj diff --from @--`.)

This is also the default behavior of `jj next` and `jj prev`, which are very confusing if you're expecting to be editing nodes in the graph directly. You can totally do that, by passing `--edit` to them, and if that's your preference you can default the flag in the config.

I do still use `jj edit` from time to time, but for the most part `jj new` gives me a better feeling of control. It was difficult initially to not want the "extra empty change" to go away, but once I accepted that there's really only one and it corresponds to a meaningful concept (it's the auto-updated container for any changes you make), I made peace with it.

Re: Jujutsu VCS: Introduction and patterns

#53

Post by danpalmer »

cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

It solves two problems. First is having a batter UI, git is well known to have a bad UI and be hard to teach. But you’re right there aren’t new capabilities.

Secondly, and more importantly, is that you can back it on to different storage mechanisms. Companies with large monotypes are often not using git (Google, Facebook,…), or are using highly specialised git (e.g. Microsoft). JJ is not just got compatible, git is a pluggable storage backend.

I mostly use JJ backing on to Piper, and the integration is excellent. I’ve also used it backing on to git. I can transfer almost all my knowledge and muscle memory between these two places.

Re: Jujutsu VCS: Introduction and patterns

#54

Post by cube2222 »

sfink wrote: post #52

I've been using jj for a month, coming from mercurial. I have settled into a usage pattern slightly different than the article describes, so that all of those `jj edit` commands made me a little itchy. I prefer to nearly always use a separate @ commit to hold any changes I make. The mental model is that there's a graph of commits, and then @ is an auto-updated commit to hold any changes I make in an editor or whateve…

I think I agree for the most part in practice. The vast majority of changes I make are on the nondescript (or actually description-containing) @ changes / "branch" tips, and then either become described changes, or get squashed / split / rebased / etc. into the right place.

Re: Jujutsu VCS: Introduction and patterns

#55

Post by [deleted] »

danpalmer wrote: post #53
cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

It solves two problems. First is having a batter UI, git is well known to have a bad UI and be hard to teach. But you’re right there aren’t new capabilities. Secondly, and more importantly, is that you can back it on to different storage mechanisms. Companies with large monotypes are often not using git (Google, Facebook,…), or are using highly specialised git (e.g. Microsoft). JJ is not just got compatible, git is a…

[deleted]

Re: Jujutsu VCS: Introduction and patterns

#56

Post by ehzy »

saulrh wrote: post #16
cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

The thing about jj is that it doesn't actually enable any new capabilities . I tell people to use emacs or vim or vscode or whatever instead of notepad because it gives them new capabilities , things that are simply unavailable unless you're talking to an LSP or running a full-powered scripting engine. jj doesn't make anything possible the way going from notepad to a real editor does. What jj does do is it makes ever…

jj is not just a new interface for git, it has a lot of new and powerful features to offer, even when you're using the git backend with a colocated repo. Just to name a few:

- deferred conflict resolution

- The very expressive revset language

- the op log and ability to undo any operation

Many things that you can do with the git cli are significantly easier and in some cases comparatively effortless using jj. If all you do is git add and git commit then you probably aren't missing out on much, but if you ever split or rebase commits you should definitely try jj.

Re: Jujutsu VCS: Introduction and patterns

#57

Post by 0cf8612b2e1e »

cube2222 wrote: post #30
0cf8612b2e1e wrote: post #28

What workflow do people adopt for tools which still do not have a concept of local-only config files? For example, VSCode only has a launch.json, which should be committed, but I might need to customize it to my environment/current problem without distributing those edits. How can I not constantly fight jj with this?

I think you could achieve this with a variation of the "Working on Two Things at the Same Time" pattern[0], also explored more widely here[1] (with e.g. using private commits). Basically, just have a local-only merge-change that combines whatever you're working on, with all your local modifications. You can then even just create new changes on top of the ` ` change, and then rebase each into your branch when you're d…

I am not proficient enough in jj to fully follow that, but it sounds promising. Especially if I can at least poison the local changes so there is no risk of sharing them.

Re: Jujutsu VCS: Introduction and patterns

#58

Post by hinkley »

ilyagr wrote: post #50
hinkley wrote: post #40

Earlier quoted context omitted.

The config file needs a lot of love. As does the help. If you clone the repo there’s a bunch of documentation and example files, but if you install jj, those do not exist.

Each release comes with a file with all the help, for example: https://github.com/jj-vcs/jj/releases/download/v0.25.0/jj-v0... In theory, packagers could put these docs somewhere. I'm not sure what the best way is to make it convenient to use. Also, I'm not sure about jj v0.25, but in the upcoming (probably tomorrow) 0.26, you can get a lot of docs by doing e.g. `jj help -k config`. Ironically, this fact is currently…

Yeah I made it as far as planning out a change to the `jj config --help` output to at least link to the documentation and then realized that my copy didn't have the documentation. Oops. And then I got occupied by some other FOSS bug and forgot to circle back.

Unfortunately there was a gap between installing it and trying it for the clever merge resolution use case I had in mind, and I've forgotten how I installed it, so I need to reverse engineer that to figure out how I got here.

Re: Jujutsu VCS: Introduction and patterns

#59

Post by justinpombrio »

saghm wrote: post #46
password4321 wrote: post #13

Earlier quoted context omitted.

> I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works) Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?

One of the main innovations in how `jj` works (in my opinion at least) is that has a concept of "immutability" for commits, which if I recall correctly is configurable with an arbitrary filter in the config, but the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable". When you run a command…

> the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable"

The default for what's immutable is actually `main` together with untracked remote branches [1]. I agree that what you suggested should be the default though. You can change it by adding this line to your `jj` config:

  [revset-aliases]
  "immutable_heads()" = "builtin_immutable_heads() | remote_bookmarks()"
(To edit your jj config, run `jj config edit --user`.)

[1] https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-...

Re: Jujutsu VCS: Introduction and patterns

#60

Post by hinkley »

necauqua wrote: post #44
hinkley wrote: post #38

The fact that jj doesn’t tell you what files have changed until you start a new commit is holding up my plans to use it. It’s frustrating for me and I imagine it would create tech support questions if I made others use it if it’s to replace git it needs some further ergonomics refinement.

It's `jj status`?.

I'll have to try it on a blank checkout because once I've run 'jj new' then 'jj st' does something similar to git st, but I had a situation on a fresh checkout where I know I'd saved changes in the IDE, git st showed them, but jj st came up as blank.

It may be that this only happens immediately after jj git init.

But any tool that lies to people is a huge red flag. Because while I can memorize that caveat it's presumptuous to assume that an entire team of people new to a tool will remember a footgun. That's on the tool not the victims.

Post reply on HN