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

381–390 of 517 posts

Re: jj – the CLI for Jujutsu

#381

Post by fallat »

steveklabnik wrote: post #231
fallat wrote: post #153

Now that Steve is part of a GitHub competitor to push jj, I see all these posts as just sales pitches.

I am quite happy for anyone to use whatever tools they find to be good. I'm also happy for anyone to use jj with whatever server they want to. It is right to be skeptical of me, but I hope to keep that integrity by continuing to talk about things that I believe are legitimately good, regardless of anything else.

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 person is really nice and always have been "for the community", but I can't shake this current framing!

Re: jj – the CLI for Jujutsu

#382

Post by baq »

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.

edit is useful and there are good reasons to use it, 'never use edit' is like 'never use goto' i.e. false - but if you're just starting out, jj new/jj squash is the way to go indeed.

(my particular favorite reasons to use jj edit are git-native tools which expect to work with uncommitted files e.g. autoformatters, linters, etc. which have been scripted in CI/dev workflows such that they cannot accept a list of files as params)

Re: jj – the CLI for Jujutsu

#383

Post by opem »

steveklabnik wrote: post #170

Hey folks! So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it. Happy to answer any questions!

I think one major difference between git and jj is how immutable their DAG is, due to the difference in how they refer to their unit of change (i.e. stable change ID with changing commit IDs vs. immutable commit ID). One implication of that is change history in a git repo feels much more immutable to the one in a jj repo. Consequently operations that involves changing the history like, undo/rebase feels much easier/flexible. Is my understanding correct?

Re: jj – the CLI for Jujutsu

#384

Post by [deleted] »

childintime wrote: post #319
jansan wrote: post #66

Earlier quoted context omitted.

It is not about starting over, like moving from CVS or Subversion to Git. jj is backend compatible to Git, so nothing really had to change on the backend. It's just that although Git was created by Linus Torvalds it is not perfect and could be more beginner friendly. But efforts to improve this should be concerted, not individual efforts. And it does not have to be jj. I just think there is room for improvement, and…

Linus? Too tired of the open source community to risk having to deal with it more. Hasn't released anything since 2005, he just drifts on the waves. So sad he doesn't see the human energy wasted on his projects, and doesn't move them into the modern era, where compatibility with the past can be dropped in favor of a much tighter feature set, while also coming free of C/C++. In short: don't count on Linus, he's been a…

[deleted]

Re: jj – the CLI for Jujutsu

#385

Post by fragmede »

tom_alexander wrote: post #372
fragmede wrote: post #356

Earlier quoted context omitted.

> these two states look completely identical No they don't. As you noted, one state is "detached head" and any competently set up shell PS1 will tell you that, or that you're on a branch by displaying the name of the branch vs the commit. > Creating new commits on anonymous branches is perfectly normal Sorry, that that's an example of more intuitive behavior on jj's partc, you've lost me. I've done that intentionally…

> any competently set up shell PS1 will tell you that I certainly hope your shell is not running `git` commands automatically for you. If so, that is a RCE vulnerability since you could extract a tarball/zip that you don't expect to be a git repository but it contains a `.git` folder with a `fsmonitor` configured to execute a malicious script: https://github.com/califio/publications/blob/main/MADBugs/vi...

Might want to let git know. It's been a part of the git source code since 2006. If there were an RCE vulnerability from using __git_ps1, one would hope it would have been found by now!

https://github.com/git/git/blob/master/contrib/completion/gi...

Re: jj – the CLI for Jujutsu

#386

Post by opem »

kevin_nisbet wrote: post #148

I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git. What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it…

I see that is an issue with many people, but now with github adding support for stacked PRs, I guess that would change

Re: jj – the CLI for Jujutsu

#387

Post by steveklabnik »

saint_yossarian wrote: post #376
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.

It's available in Debian sid, although a few versions behind: https://packages.debian.org/search?searchon=names&suite=all&...

You know, I went and searched before I posted. I wonder why it didn’t come up! Thanks.

Re: jj – the CLI for Jujutsu

#388

Post by steveklabnik »

fallat wrote: post #381
steveklabnik wrote: post #231

Earlier quoted context omitted.

I am quite happy for anyone to use whatever tools they find to be good. I'm also happy for anyone to use jj with whatever server they want to. It is right to be skeptical of me, but I hope to keep that integrity by continuing to talk about things that I believe are legitimately good, regardless of anything else.

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.

Re: jj – the CLI for Jujutsu

#389

Post by steveklabnik »

opem wrote: post #383
steveklabnik wrote: post #170

Hey folks! So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it. Happy to answer any questions!

I think one major difference between git and jj is how immutable their DAG is, due to the difference in how they refer to their unit of change (i.e. stable change ID with changing commit IDs vs. immutable commit ID). One implication of that is change history in a git repo feels much more immutable to the one in a jj repo. Consequently operations that involves changing the history like, undo/rebase feels much easier/f…

Sorta! I think it can feel that way at times, but also the opposite. jj’s changes are immutable in the same way commits are, when you modify a change, it makes a new immutable commit and associates that with the change. So on the literal level, they’re the same.

But it’s true that mutating history is easy and sometimes even automatic with jj, whereas it’s not with git. So that could make it feel more mutable. On the other hand, jj has the concept of mutable vs immutable commits; jj will present you from modifying certain changes unless you pass in a flag to override it. So in some ways, it’s more immutable than git.

Just really depends on your perspective.

Re: jj – the CLI for Jujutsu

#390

Post by fragmede »

MrJohz wrote: post #373
fragmede wrote: post #356

Earlier quoted context omitted.

> these two states look completely identical No they don't. As you noted, one state is "detached head" and any competently set up shell PS1 will tell you that, or that you're on a branch by displaying the name of the branch vs the commit. > Creating new commits on anonymous branches is perfectly normal Sorry, that that's an example of more intuitive behavior on jj's partc, you've lost me. I've done that intentionally…

They look identical to people who don't know what to look for, and who don't realise that these two states are different, which is the key thing. You can also distinguish them by running `git status`, but that's kind of the point: there's some magic state living in .git/ that changes how a bunch of commands you run work, and you need to understand how that state works in order to correctly use git. Why not just remov…

My command looks like either:

    fragmede@laptop:(abranch)~/projects/project-foo$
or fragmede@laptop:(abcdef)~/projects/project-foo$

Depending on if abranch is checked out, or abcdef which may be HEAD of abranch is checked out.

If you're having to run `git status` by hand to figure out which of the two states you're in, something's gone wrong. (That something being your PS1 config.) If people are having trouble with that, I can see why switching to a system that doesn't have that problem, it just that it doesn't seem like it should even be problem to begin with. (It's not that it's not useful to have unnamed branches and to commit to them, just that it's not a intro-to-git level skill. Throwing people into the deep end of the git pool and being surprised when some people sink, isn't a good recipe for getting people to like using git.)

> What's wrong with unnamed branches? As you point out, those commits kinda just go into the ether, and must be dug out via reflog, so operationally, why would you do that to yourself. Separate from that though, do you "cd" into the project directory, and then just randomly start writing code, or is there some idea of what you're working on. Either a (Jira) ticket name/number, or at least some idea of the bug or feature you wanna work on. Or am I crazy (which I am open to the possibilty) and that people do just "cd" into some code and just start writing stuff?

VCS aside, nothing worse than opening Google docs/a document folder and seeing a list of 50 "Untitled document" files an my habit of naming branches comes from that. Even though I'm capable of digging random commits out of reflog, if all of those commits are on unnamed branches, and have helpful commit messages like "wip" or "poop", figuring out the right commit is gonna be an exercise in frustration.

As long as you've got something that works for you though, to each their own. I've been using too long for me to change.

Post reply on HN