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

jj – the CLI for Jujutsu

steveklabnik.github.io

Post reply on HN
Print view View original

401–410 of 517 posts

Re: jj – the CLI for Jujutsu

#401

Post by steveklabnik »

QuiDortDine wrote: post #396
steveklabnik wrote: post #336

Earlier quoted context omitted.

You do need Cargo to build from source. If you're on Arch, gentoo, or openSUSE, you can use the package. It is true that Debian has not packaged jj yet. It'll get there, and it's fine if you'd rather wait until things are more mature.

Thanks! I hope I didn't come off as too dismissive, I'm hearing a lot of good things about Jujutsu. As a developer though, I've never wanted to build from source (probably in the minority on that front).

Nah, you're right that installing a compiler toolchain to build a project is a pain in the butt if you don't already have it. It's a legitimate thing, but it does mean that you won't be adopting more cutting edge tools, which is also just fine! I've done the same with projects built with tools I don't have installed too.

Re: jj – the CLI for Jujutsu

#402

Post by steveklabnik »

Zizizizz wrote: post #399
fragmede wrote: post #391

Earlier quoted context omitted.

Fascinating. The benefit it brings is you can map the branch to its name. Of the, say, 10 branches you've got checked out, how do you know which branch maps to jira-123 and which one maps to jira-234, or if you're using names, which anonymous branch maps to addFeatureA or fixBugB? More to the point though, what tooling is there on top of raw jj/git? Specifically, there's a jira cli (well, multiple) as well as a gh cl…

You can name branches in JJ too, they're just called bookmarks. git checkout main git pull git switch -c jira-234 ... git commit git push -u origin main jj git fetch jj new main ... jj commit jj b(ookmark) c(reate) jira-234 -r @- jj b(ookmark) t(rack) jira-234@origin jj git push

Right, this is a good point: you can if you want to, or if you're working with a system that requires them.

Just in practice, anonymous branches end up feeling very natural, especially during development, and especially if your code review tooling doesn't require names.

Re: jj – the CLI for Jujutsu

#403

Post by nvader »

VMG wrote: post #12
7e wrote: post #10

Is it better for AIs? That’s the only reason I would care.

I've had mixed results. Most models don't have a 100% correct CLI usage and either hallucinate or use some deprecated patterns. However `jj undo` and the jj architecture generally make it difficult for agents to screw something up in a way that cannot be recovered.

Try using https://github.com/danverbraganza/jujutsu-skill

This is enough of a command reference that with it, agents are able to work with jj pretty well.

Re: jj – the CLI for Jujutsu

#404

Post by 59nadir »

fmckdkxkc wrote: post #80
tiborsaas wrote: post #54

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…

Personally haven’t used jj but as far as dvcs’s are concerned Fossil is great complement to Git because it does things differently than git and truly has a decentralized feel. The autosync feature is really nice too, and you can store backup repos in cloud storage folders and auto sync to those as well.

Fossil is delightful and definitely nails a feeling of decentralization that I think we ruined completely with `git` by constantly centering around centralized repositories.

I also find it interesting that so many people want to switch to something that's not `git` but are simultaneously somehow super invested in it being basically just `git`.

Most teams could switch to Fossil and just have a better time overall. It's made for smaller, high-trust teams, `git` is not. Fossil also manages to actually support external contributions just fine; it's just that it's not the default.

Re: jj – the CLI for Jujutsu

#405

Post by frio »

joshka wrote: post #62
tiborsaas wrote: post #54

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…

> Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. A good way to think of it is that jj new is an empty git staging area. There's still a `jj commit` command that allows you to desc then jj new. > I also often end up with in a dirty repo state with multiple changes belonging…

> A good way to think of it is that jj new is an empty git staging area. There's still a `jj commit` command that allows you to desc then jj new.

This always made me feel uncomfy using `jj`. Something that I didn't realise for a while is that `jj` automatically cleans up/garbage collects empty commits. I don't write as much code as I used to, but I still have to interact with, debug and test our product a _lot_ in order to support other engineers, so my workflow was effectively:

    git checkout master
    git fetch
    git rebase # can be just git pull but I've always preferred doing this independently
    _work_/investigate
    git checkout HEAD ./the-project # cleanup the things I changed while investigating
```

Running `jj new master@origin` felt odd because I was creating a commit, but... when I realised that those commits don't last, things felt better. When I then realised that if I made a change or two while investigating, that these were basically stashed for free, it actually improved my workflow. I don't often have to go back to them, but knowing that they're there has been nice!

Re: jj – the CLI for Jujutsu

#406

Post by fallat »

steveklabnik wrote: post #388
fallat wrote: post #381

Earlier quoted context omitted.

Thanks for the reply Steve - I think it's only natural, and charitably unintentional :) But almost everything I've seen upvoted around the Internet from you has been about jj and being directly tied to east river source control... I think that's a reasonable framing. I can only hope me signalling this maybe changes something. While I'm not a fan of jj (I'd much rather Pijul were to eat the world), I think you as a pe…

I mean, most people seem to think I solely post about AI these days, so it’s kinda funny to run into someone that feels otherwise! I’m not sure why I’d stop posting about a project I’ve been passionate about for years, just because my job is adjacent to it.

You can't say it's adjacent to it, when your job directly involves the technology. You'd stop posting because anything you say about jj could be interpreted as a sales pitch for jj, and a lot of people can be turned off by that. That's one reason. Our lack of creativity is not proof of no more.

But I don't think "stop writing" is the only strategy to jump on...

Or maybe I'm just extremely unlucky to have only caught these kinds of posts and gained this framing! Totally possible.

Re: jj – the CLI for Jujutsu

#407

Post by dwattttt »

tom_alexander wrote: post #359
sswatson wrote: post #333

Earlier quoted context omitted.

I find this kind of advice to be a more scathing indictment of an interface than a critic could ever muster: asking users to forego available functionality so that some sense of order can be imposed.

That goes in the same bucket as rebase. Until you know what it does, you'll be fine avoiding it.

Since people are sharing their experiences and my recent one is relevant to edit, I'll go:

Working on a feature recently, I ended up making 3 changes ("commits") on top of each other and hopping between them via jj edit.

The first change wasn't feature specific, it was extending the base project in preparation.

The second change just added a doc describing all the changes needed for the feature.

The third change removed the doc as parts were implemented, bit by bit.

As I progressed on the third change & found stuff I'd missed at the start of this process, I jumped back to edit the first change (maybe I had a bug in that base project extension) and the second change (oh hey, I found something else that needed to be done for the feature).

It sounds crazy compared to a git workflow, but at the end of the process I have 3 changes, all tested & working. If I was doing this with git, I'd have to rebase/squash to get the final changes into a neat clear history.

Re: jj – the CLI for Jujutsu

#408

Post by saghm »

nchagnet wrote: post #380
saghm wrote: post #127

Earlier quoted context omitted.

It's been over a year since I last used git manually in the CLI, and I've exclusively worked with git remotes. The only time I had any friction was on a team where stale code-gen output was checked into the repo and for whatever reason no one was willing to either add it to the `.gitignore` or commit (pun intended) to keeping it up to date, meaning that I had to manually remove the changes from when I compiled before…

For what it's worth, you can have your own local gitignore by adding patterns to .git/info/exclude. It's quite useful in this exact situation.

I did try this, but for whatever reason it kept getting added back automatically. I forget the details of exactly why it was happening because it was close to a year ago, and in the compatibility guide it says this is supported, but I'm not sure if it was at the time or I was running into something different. This was a contract gig for me where I knew it would be ending within a month or so, which meant I didn't bother spending a ton of time trying to figure out a long-term solution.

Re: jj – the CLI for Jujutsu

#409

Post by saghm »

nightski wrote: post #323
saghm wrote: post #294

Earlier quoted context omitted.

That's my overall point: the argument itself (with respect to the current state of the repo) is what determines the behavior. I don't think this is anywhere close to as intuitive as commands that only ever accept one "type" of argument (and erroring if it's different).

I stand corrected by this one scenario, but I’ve been using git for over a decade and never found that useful. Just don’t use checkout on a file path, there is no need.

"Just don't accidentally do things wrong" is also the way to avoid null pointer errors, type mismatches in dynamically typed languages, UB in C/C++. It works, until it doesn't, and in practice that happens pretty quickly. Personally, I like things that have proper safety checks.

Re: jj – the CLI for Jujutsu

#410

Post by nchmy »

tiborsaas wrote: post #54

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…

JJ doesnt prefer you to do anything. I regularly just create description-free commits, do whatever, then name them later (or squash, split, absorb the changes into other commits). It is exceptionally flexible and forgiving. Even moreso if you use jjui, the best TUI ive ever used.
Post reply on HN