Live data from Hacker News

jj – the CLI for Jujutsu

steveklabnik.github.io

211–220 of 517 posts

Re: jj – the CLI for Jujutsu

#211
post #117

"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.

A couple things off the top of my head:

- You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later.

- Manipulating commits is super easy (especially with jjui). I reorder commits all the time and move them between branches. Of course you can also squash and split commits, but that's already easy in git. Back when I was using git, I would rarely touch previous commits other than the occasional squash or rename. But now I frequently manipulate the commit history of my branch to make it more readable and organized.

- jj acts as a VCS for your VCS. It has an operation log that is a history of the state of the git repository. So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone.

- Unnamed branches is the feature that has changed my workflow the most. It's hard to explain, so I probably won't do it justice. Basically you stop thinking about things in terms of branches and instead just see it as a graph of commits. While I'm experimenting/exploring how to implement or refactor something, I can create "sub-branches" and switch between them. Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I want to test something but I have current changes, I just `jj new`. And if I want to go back, I just make a new commit off of the previous one. And all these commits stick around, so I can go back to something I tried before. Hopefully this made some sense.

Also note that jj is fully compatible with git. I use it at work and all my coworkers use git. So it feels more like a git client than a git replacement.

Re: jj – the CLI for Jujutsu

#212

One of my favorite jj features is "jj absorb". For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit. Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to. Oh, and not having to…

git absorb exists too fyi

Not by default: https://github.com/tummychow/git-absorb

Re: jj – the CLI for Jujutsu

#214
post #106

Nope, git is good enough, and is the global standard. We don't need more new VCS.

Great opinion. Have you tried it? It takes just 30 minutes to wash all the Stockholm syndrome off of you.

Not necessarily. I used jj for a couple of weeks and found it to be a complete waste of time.

For an advanced user, it did not offer anything I cannot quickly solve in git. Which is probably the wrong thing to optimize in the first place, because even though I frequently rewrite history and split commits during normal worklfow, it takes so little time that improving something else would yield greater returns.

We (not royal we) don't usually go out of our way repeating negative experiences with these tools, so you build a very skewed view of their adoption.

Re: jj – the CLI for Jujutsu

#215
post #38

Earlier quoted context omitted.

Coming from mercurial (which is older than git), git doesn't understand a branch. Instead of a branch you get a tag that moves, which is very different. Too often I'm trying to figure out where something came in, and but there is just a series of commits with no information of which commits are related. Git then developed the squash+rebase workflow which softof gets around this, but it makes commit longer (bad), and…

> Coming from mercurial (which is older than git) Git is older than mercurial by 12 days. Bazaar has git beat by about the same amount of time. The major DVCSes all came out within a month of each other. > But Linus pushed git and people followed like sheep. I don't think this is true. Until around 2010-2011 or so, projects moving to DVCS seemed to pick up not git but mercurial. The main impetus I think was not Linux…

way way back in the day I did some digging into all three - and picked bazaar for my personal projects. that didn't last long lol

Re: jj – the CLI for Jujutsu

#216
post #105

JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects. What has a change is ast-based version control. You adding a feature to a function that uses a struct I renamed shouldn't be a conflict. Those actions don't conf…

Did you confirm that the network effects are applicable here before posting that?

Nope. As mentioned "What is jj and why should I care?" didn't cover it and I timeboxed jj advocacy to the page that says it will get me to care.

Re: jj – the CLI for Jujutsu

#217

Earlier quoted context omitted.

To be honest, while Steve's tutorial was what got me interested in jj, other tutorials were better in actually helping me understand it.

This is why I'm glad we have many of them! Not everyone is going to resonate with my writing style.

Yes, but it's a sad state of affairs that the official jj docs point to your tutorial, which is incomplete (and IIRC, more incomplete than in the past - I think you took down some topics).

Re: jj – the CLI for Jujutsu

#218
post #27

I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you creat…

Wow, that’s a total deal breaker to me. Using git may require a complex mental model, but at least it’s not doing anything I didn’t ask for.

`jj edit` is quite literally asking for that.

GP is holding it wrong. If you don’t want to edit a commit, don’t ask to edit it. Use `jj new`.

Re: jj – the CLI for Jujutsu

#220
post #172
post #104

Earlier quoted context omitted.

> preventing you from accidentally rebasing changes that have been shared. I think this ruins it for me then. I push my in-progress work, to my in-progress branches (then git-squash or whatever later, if needed). It makes switching between (lab) computers, dead or not, trivial. Is there some "live remote" feature that could work for me, that just constantly force pushes to enabled branches?

Yes, almost all JJ users do this constantly. Just "track" the particular branch. JJ has an idea that only some commits are immutable, the set of "immutable heads", and the default logic is something like "The main branch is always immutable, remote branches are immutable, 'tracked' remote branches are mutable." In other words, tracking a remote branch removes it from the set of immutable heads. So just run: jj bookma…

This is all incredible. I even see a great looking GUI [1]!

[1] https://jj-gui.com/

Post reply on HN