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

81–90 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#81

Post by sfink »

steveklabnik wrote: post #61
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…

The nickname for these two is the "edit workflow" vs the "squash workflow," and both are good to know, for sure!

Sorry, I knew I remembered reading about the two somewhere but could not figure out where. I searched through the jj page for it. Only later did I remember that it came from your jj guide, which I still had open in a tab. I wish I had pointed to your explanation, it's much more clear.

Better late than never: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

Re: Jujutsu VCS: Introduction and patterns

#82

Post by BeetleB »

pkulak wrote: post #69
mamcx wrote: post #14

Earlier quoted context omitted.

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60…

> Nobody else knows you use `jj`, so no barrier to adoption. All my PRs now have branches named "push-kjasdfkhdf", so it's not terribly well hidden. :D

You can name them if you want.

Re: Jujutsu VCS: Introduction and patterns

#83

Post by stouset »

ashenke wrote: post #80
gcr wrote: post #78

Earlier quoted context omitted.

As long as you don't use `--allow-backward` or `--ignore-immutable`, and as long as everyone sticks to their own feature branches, this shouldn't be possible. The operation log makes jj quite safe. There's a command to restore the entire working copy + history to an earlier state in case you screw something up. Even this operation log is itself versioned, so you can undo the undo if you screwed the undo up, ad infini…

For every feature we usually have two developers working on it, one frontend and one backend, working on the same feature branch. Would Jujitsu cause a problem in this context?

I haven't used this workflow personally, but it should be fine.

`jj git push` does an equivalent to `--force-with-lease`, so if there are remote commits that are later than what your current bookmark points to, it won't overwrite them. You can `jj git fetch`, it'll update your bookmark, and you can choose to put your new commits onto the updated sequence of commits wherever they belong.

Re: Jujutsu VCS: Introduction and patterns

#84

Post by stouset »

password4321 wrote: post #13
dartos wrote: post #8

Earlier quoted context omitted.

I switched from git to jj a few months ago, so I may have some insight. I used it at work, where everyone used git, and there were 0 issues. What I really like about it is how changes are sort of soft committed right away and, when I checkout a different branch or change, I don’t need to stash my changes and remember the stack of stashes. Rebasing and merging feel a little easier, but that might just be because “ours…

> 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?

If you require a physical touch for every sign operation on your YubiKey and you sign all your commits, you are going to have a bad time with jujutsu. That is somewhat unavoidable. If you are open to caching your credentials and only requiring a physical touch once every so often, this pain goes away entirely. If a physical touch for every sign is nonnegotiable, this probably isn't going to be a tool that works for you.

Jujutsu rebases multiple commits at once almost exactly the same way git does it. The three huge improvements are: 1) rebases happen automatically for descendent commits when their parents are modified, 2) rebases happen entirely in-memory and so don't require filesystem operations, which is an enormous performance benefit, and 3) rebase conflicts are a first-class citizen and doesn't require interrupting everything to drop you into a wedged rebase so you can fix it.

The third aspect combined with the first one means you can just jump to where a rebase conflict occurred, fix it, and… you're done. All the children are fixed for you automatically. If there were more, you can fix them up in the order that makes sense to you and you don't need to completely finish before being able to jump around elsewhere in the repo.

Re: Jujutsu VCS: Introduction and patterns

#85

Post by stouset »

zellyn wrote: post #20
Hasu wrote: post #10

Earlier quoted context omitted.

> when I can see something that beats the git cli hands down. Then you should switch to jujutsu several months ago. It's the biggest improvement to my development workflow in over a decade. The last change that was as big was git itself.

I can second this opinion. The moment I read "something that beats the git cli hands down" I command-F searched for "hands down" to find this comment or make it myself.

Thirded. I relegated jj-related articles to /dev/null for a long time having believed nothing was likely to supplant git. Then… wow, actually almost exactly a year ago something moved me to read the `jj init` post here. I read it, it was intriguing, I figured I'd give it a try later that week.

I wasn't hopeful. I have a lot of git's working model in my head. Replacing it was going to be hard but hey, might as well kick the tires.

I was productive that day. I knew enough to completely eliminate git from my workflow two days later. I have never looked back, and now I come to sing its praises every time an article is posted. It's immensely fun having seen the proportion of commenters in these threads start tilting sharply in the direction of more and more of HN having used it and loving it.

(also, hey zellyn!)

Re: Jujutsu VCS: Introduction and patterns

#86

Post by stouset »

mixmastamyk wrote: post #29
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…

Yes, so far these jj blog posts do not sell it well at all. Not to mention the rainbow colors are a bit of a turnoff. I like a little color here and there, but not ransom-note style. Monochrome effects are available folks.

`jj --config ui.color=never`

Maybe the blog posts don't sell it well, but I find it pretty telling that bordering on zero people ever enter the comment section for Jujutsu posts to complain about a bad experience they had. Just dozens upon dozens of people singing its praises.

Think about literally other technology post on this site. Nothing is universally loved.

Re: Jujutsu VCS: Introduction and patterns

#87

Post by stouset »

hinkley wrote: post #60
necauqua wrote: post #44

Earlier quoted context omitted.

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 presum…

With all due respect, it sounds like you might have some confusion about what happened. If you run `jj new`, `jj st` will virtually by definition show a clean working copy. You've created a new, empty revision, and as a consequence there are zero changes which have been made in that empty revision.

Asserting that `jj` "lies to people" is… probably uncalled for here. I'm not going to say it's impossible for the two commands to produce incongruent output, but knowing how they work it seems pretty unlikely. I think it's far more likely that either there was some confusion on your part (two different tabs in two separate projects?), you did something you didn't fully understand with a new and unfamiliar tool you were playing with (perhaps you misunderstood what `jj new` does?), or some other very reasonable and understandable thing occurred that falls pretty far short of "the tool lied to you".

Re: Jujutsu VCS: Introduction and patterns

#88

Post by stouset »

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

Earlier quoted context omitted.

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.

Honestly that does sound like a really frustrating corner case.

Re: Jujutsu VCS: Introduction and patterns

#89

Post by mixmastamyk »

stouset wrote: post #86
mixmastamyk wrote: post #29

Earlier quoted context omitted.

Yes, so far these jj blog posts do not sell it well at all. Not to mention the rainbow colors are a bit of a turnoff. I like a little color here and there, but not ransom-note style. Monochrome effects are available folks.

`jj --config ui.color=never` Maybe the blog posts don't sell it well, but I find it pretty telling that bordering on zero people ever enter the comment section for Jujutsu posts to complain about a bad experience they had. Just dozens upon dozens of people singing its praises. Think about literally other technology post on this site. Nothing is universally loved.

Just said I don't want color==never.

That's the problem, no one can cogently/concisely explain why. I don't love git but have sanded its rough edges already. Gitlab did the rest.

I recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/ Doesn't have to be this long but note his writing style.

Re: Jujutsu VCS: Introduction and patterns

#90

Post by stouset »

mixmastamyk wrote: post #89
stouset wrote: post #86

Earlier quoted context omitted.

`jj --config ui.color=never` Maybe the blog posts don't sell it well, but I find it pretty telling that bordering on zero people ever enter the comment section for Jujutsu posts to complain about a bad experience they had. Just dozens upon dozens of people singing its praises. Think about literally other technology post on this site. Nothing is universally loved.

Just said I don't want color==never. That's the problem, no one can cogently/concisely explain why. I don't love git but have sanded its rough edges already. Gitlab did the rest. I recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/ Doesn't have to be this long but note his writing style.

> no one can cogently/concisely explain why

There are literally dozens of examples of comments in this thread doing exactly that. Perhaps those explanations don't resonate with you and that's fine.

Post reply on HN