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

61–70 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#61

Post by steveklabnik »

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!

Re: Jujutsu VCS: Introduction and patterns

#62

Post by diego898 »

cube2222 wrote: post #47
diego898 wrote: post #45

Earlier quoted context omitted.

How does this work with a shared remote branch? I know in git when you alter your history you can do a `git push --force-with-lease` as a safer `--force` - do you have to do this frequently with jj "rewriting history" (from a git perspective)?

Yeah, `jj git push` acts as an equivalent (according to my experience and understanding) to `git push --force-with-lease`, always. You don't have to pass an explicit --force, nor an explicit lease-related argument. As you say, rewriting the commits underlying changes happens frequently, so this would otherwise be pretty annoying. There's also `jj git push --dry-run` to preview which branches would be updated in what…

Thanks that makes sense - just feels weird to go from years of “be very careful rewriting history with git, especially at work” to jj rewriting everything all the time - can’t shake the feeling there’s a clash somewhere waiting to happen

Re: Jujutsu VCS: Introduction and patterns

#63

Post by cube2222 »

diego898 wrote: post #62
cube2222 wrote: post #47

Earlier quoted context omitted.

Yeah, `jj git push` acts as an equivalent (according to my experience and understanding) to `git push --force-with-lease`, always. You don't have to pass an explicit --force, nor an explicit lease-related argument. As you say, rewriting the commits underlying changes happens frequently, so this would otherwise be pretty annoying. There's also `jj git push --dry-run` to preview which branches would be updated in what…

Thanks that makes sense - just feels weird to go from years of “be very careful rewriting history with git, especially at work” to jj rewriting everything all the time - can’t shake the feeling there’s a clash somewhere waiting to happen

You can customize the immutable commits option to specify which commits you want to be blocked from changing.

By default that’s only the main branch and untracked remote branches. For me that makes sense as I’m generally fine with constantly rewriting my feature branches.

However, if you want it to e.g. block you from rewriting anything that you’ve already pushed to the remote, you can set it to treat anything that’s pushed to the remote as immutable, too, as another commenter described [0].

[0]: https://news.ycombinator.com/item?id=42940329

Re: Jujutsu VCS: Introduction and patterns

#65

Post by saulrh »

sunshowers wrote: post #24
saulrh wrote: post #16

Earlier quoted context omitted.

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…

As a source control expert and jj's number one fan [1], I would count being able to defer merge conflict resolution as a new capability, FWIW. In general I think jj's greater than the sum of its (very good) parts because of how its features work together to create a coherent and pleasant user experience. [1] the top testimonial on https://jj-vcs.github.io/jj/latest/testimonials/ is mine

I guess I was thinking in terms of the patches you push up to github. `jj` is a joy to use and it absolutely enables me to implement workflows that I wouldn't even vaguely consider without it helping me; the big one I think of is the one where you work in a merged dir with like six parents and use `jj absorb` to instantly spread your changes out to the different PRs. I've been forced to do that in git. It was a nightmare and took me two days. Not impossible! Just utterly impractical. `jj` takes end results that were theoretically-possible-but-practically-infeasible and makes them usable. Which I suppose counts as a new capability from the UX perspective. :P

Re: Jujutsu VCS: Introduction and patterns

#66

Post by sunshowers »

saulrh wrote: post #65
sunshowers wrote: post #24

Earlier quoted context omitted.

As a source control expert and jj's number one fan [1], I would count being able to defer merge conflict resolution as a new capability, FWIW. In general I think jj's greater than the sum of its (very good) parts because of how its features work together to create a coherent and pleasant user experience. [1] the top testimonial on https://jj-vcs.github.io/jj/latest/testimonials/ is mine

I guess I was thinking in terms of the patches you push up to github. `jj` is a joy to use and it absolutely enables me to implement workflows that I wouldn't even vaguely consider without it helping me; the big one I think of is the one where you work in a merged dir with like six parents and use `jj absorb` to instantly spread your changes out to the different PRs. I've been forced to do that in git. It was a night…

Absolutely! jj is a real advancement in the state of the art. I think it's the second time in the history of source control where the authors of a new system have spent a long time working on existing systems + deploying them at scale, and have brought their full expertise to bear on the design of the new system.

(The first was BitKeeper, which also was a tremendous achievement.)

Re: Jujutsu VCS: Introduction and patterns

#68

Post by dragonwriter »

pkulak wrote: post #67

>> Changes in jj can be marked with bookmarks (what jj calls branches), JJ actually calls its bookmarks "bookmarks". Maybe these two words got accidentally flipped?

No, the English structure " ... what jj calls " just has an annoying semantic ambiguity, and can either mean " is the name used by jj for the thing that is more commonly referred to as " or "the thing more generally called is referred to as by jj", which is expected to be resolved by the reader on the basis of whether or is the generic term they are familiar with.

Re: Jujutsu VCS: Introduction and patterns

#69

Post by pkulak »

mamcx wrote: post #14
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…

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

Re: Jujutsu VCS: Introduction and patterns

#70

Post by pkulak »

12_throw_away wrote: post #23
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…

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a…

I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see history, everything. There's almost no need for a dedicated plugin.

When I first started using jj, I remember just doing a "jj st" would commit everything and I'd lose all my editor support. It was pretty much the only part that got worse after switching. And now it's "fixed". If anyone knows more about jj than me, I'd love to know if I'm right about this, or just hallucinating. :D

Post reply on HN