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

421–430 of 517 posts

Re: jj – the CLI for Jujutsu

#421

Post by MrJohz »

fragmede wrote: post #390
MrJohz wrote: post #373

Earlier quoted context omitted.

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

The only thing that changed in the two things you wrote was `ranch` -> `cdef`. Every other part of that PS1 output was the same.

Now put yourself in the shoes of a git novice and ask yourself if you'd always notice the difference. At least from my experience, they often don't, especially if they're concentrating on something else, it if they're using an IDE and the visual information about which branch/commit is checked out.

I don't think you're crazy, I think you're just too used to this sort of stuff to remember what it was like to still be learning git. When I say people make these sorts of mistakes, I'm thinking about real colleagues of mine who have made exactly these mistakes and then panicked that commits suddenly had disappeared.

Similarly, I think to you, unnamed branches feel like something complicated because in git that are. Git makes it very easy for commits to seemingly disappear into the ether, even though they are still there. But in jj, they don't disappear - they remain very visible, and the log UI shows them in a way that makes it clear where they come from. The default log UI is something like git's --graph output, which means you see how the different commits interact with each other. I really recommend having a look at the output of `jj log`, because I think then it'll be a lot clearer what I mean when I say that it's not hard to figure out what the right commit is.

Re: jj – the CLI for Jujutsu

#422

Post by crazygringo »

octocop wrote: post #157

Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.

Yes they are. I am. Many other people are too.

git was a great step forwards, but its conceptual model just doesn't map well to a lot of workflows, and some very simple things are very difficult or impossible with it. It was designed using a certain set of assumptions and primitives, and other assumptions and primitives turn out to be much more suitable for certain workflows.

I don't know if jj is the perfect answer, but it's a huge step forwards in many ways.

Re: jj – the CLI for Jujutsu

#423

Post by Balinares »

motbus3 wrote: post #136
minraws wrote: post #119

Earlier quoted context omitted.

think of jj like, I want to build xyz, ``` jj desc -m "feat: x y & z" ``` do the work. ``` jj split ``` Split up the parts and files that you want to be separate and name them. This will also allow you to rename stuff. ``` jj bookmark create worklabel-1 -r rev1 jj bookmark create worklabel-2 -r rev2 # Push both commits # since we just split them they are likely not inter-dependent # so you can rebase them both to bas…

I am dumb. why is that better than a git branch or a git worktree ?

In sort of the same way juggling apples is better than juggling hand grenades: it's mostly the same in the simple cases, but once you start doing the really fancy stuff, one of the two will get you a lot fewer messy explosions.

(Your question is not dumb, BTW. The pithy answer is: UX matters, but it does so in ways that can be hard to convey since it's about the amount of cognition you need to put in a given thing to get a desired outcome, and that's tricky to express in text. Also there will always be some people for whom a new mental model just doesn't work. That doesn't make them dumb either, at least provided they have the wisdom not to petulantly piss in the cornflakes of those who get a kick out of how much better the new thing works for them.)

Re: jj – the CLI for Jujutsu

#424

Post by cindyllm »

eddd-ddde wrote: post #419
beanjuiceII wrote: post #377

Earlier quoted context omitted.

being a good engineer is also understanding when something is a waste of time because the gain is insignificant 99% of the time

Using "good engineering" as an argument against learning is definitely an interesting approach.

[dead]

Re: jj – the CLI for Jujutsu

#425

Post by stavros »

frio wrote: post #405
joshka wrote: post #62

Earlier quoted context omitted.

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

I think calling them "commits" is doing it a disservice because it's not the same as git commits, and the differences confuse people coming from git. I'd say "jj changes are like git commits, except they're mutable, so you can freely move edits between them. They only become immutable when you push/share them with people"..

It's a mouthful, but it's more accurate and may be less confusing.

Re: jj – the CLI for Jujutsu

#426

Post by em-bee »

systems wrote: post #90

its almost impossible for me to tell if this better or worst than git i read few things about jj, and my conclusion 1. its different 2. very few user would really care about this difference i think git is good (not good enough, good just good, or really good) and unlike shells, i cant think of a reason to have mass migration to it people use zsh because apple choose it, and pwsh because microsoft settled on it, on li…

we may have not been able to replace bash yet, but the popularity of alternative shells that are not bash compatible is growing. besides nushell there are fish, elvish, murex, oils (also includes a bash compatible mode to help with the transition) and probably some others that i missed. i see more and more tooling support for some of these, which shows that usage of these shells is growing.

Re: jj – the CLI for Jujutsu

#427

Post by dcre »

beanjuiceII wrote: post #377
compiler-guy wrote: post #227

One of the things that makes jj worth trying out is simply the fact that it is different than git, and having exposure to more than one way of doing things is a good thing. Even if you don't adopt it (and I didn't), it's easy to think that "this way is the only way", and seeing how systems other than your own preferred one manage workflows and issues is very useful for perspective. That doesn't mean you should try ev…

being a good engineer is also understanding when something is a waste of time because the gain is insignificant 99% of the time

It seems like all of your comments are like this. Consider stopping that!

Re: jj – the CLI for Jujutsu

#428

Post by medler »

embedding-shape wrote: post #144
saghm wrote: post #113

Earlier quoted context omitted.

The idiom here is use `edit` if you want to edit a commit, and use `new` if you want to make a new commit. This works identically whether you specify the commit via branch name or commit id. I'm not sure why people are saying not to use `edit` ever. It's basically just a shorthand for staging and amending changes in an existing commit, and there's still a use case for that; it's just not "I want to see the changes on…

> Just don't ever use `edit`, > The idiom here is use `edit` if you want to edit a commit You know, you guys have fun with that, I'll continue using git which (probably) has the same amount of warts, but I already know them. I'll continue to refer new VCS users to jj, seems a lot easier to learn, but really don't have the interest to re-learn a bunch of ever-changing idioms.

jj has far fewer warts than git. You don’t have to learn every jj idiom, you just have to find a workflow you like, which you will, quickly, because it’s so easy to use. Personally I don’t know why anyone uses `edit` but if they like it then I’m happy for them.

Re: jj – the CLI for Jujutsu

#429

Post by dwattttt »

beanjuiceII wrote: post #377
compiler-guy wrote: post #227

One of the things that makes jj worth trying out is simply the fact that it is different than git, and having exposure to more than one way of doing things is a good thing. Even if you don't adopt it (and I didn't), it's easy to think that "this way is the only way", and seeing how systems other than your own preferred one manage workflows and issues is very useful for perspective. That doesn't mean you should try ev…

being a good engineer is also understanding when something is a waste of time because the gain is insignificant 99% of the time

I think siblings point needs to be made more sharply: this could've gone somewhere good, "I evaluated it and found the gain was not worth the cost to change", but instead went to "the gain from a change is insignificant 99% of the time, so it's not worth understanding it".

The latter is poor engineering.

Re: jj – the CLI for Jujutsu

#430

Post by [deleted] »

MrJohz wrote: post #421
fragmede wrote: post #390

Earlier quoted context omitted.

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

The only thing that changed in the two things you wrote was `ranch` -> `cdef`. Every other part of that PS1 output was the same. Now put yourself in the shoes of a git novice and ask yourself if you'd always notice the difference. At least from my experience, they often don't, especially if they're concentrating on something else, it if they're using an IDE and the visual information about which branch/commit is chec…

[deleted]
Post reply on HN