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

281–290 of 517 posts

Re: jj – the CLI for Jujutsu

#281

Post by steveklabnik »

andrewdea wrote: post #202
jrockway wrote: post #139

jj is great and while it was an adjustment at first, I've never looked back. I feel like when you're working with other people, things never get reviewed and merged as quickly as you'd like. With jj, it's pretty low-cost to have a bunch of PRs open at once, and you can do something like `jj new ` to build stuff that requires all 3. This lets me do things like... not do a big refactoring in the same PR as adding a fea…

I'm having trouble understanding the value of this and most other supposed advantages of jj I'm seeing. I'm trying to pinpoint if it's because 1) my workflow doesn't need jj's fancy stuff, 2) I've gotten so used to `git`'s "flaws" that I don't notice them, or 3) the git porcelain I use (magit) does a good enough job at managing the flaws. If you need to build on something that requires changes from 3 open PRs, can't…

For me, it wasn't so much that jj enabled things I couldn't do before, though there are some things. What it enabled was me doing the things I was doing, but in a more easy way. This also leads you to do things that you can do, but sometimes avoid because it's a lot of work.

Re: jj – the CLI for Jujutsu

#282

Post by newsoftheday »

pheggs wrote: post #252

I was already pretty happy with svn to be honest, I dont see myself switching away from the industry standard today for no substantial reason. in my opinion git was only able to change the standard thanks to github and a popular author (i love git and its branching, but I dont think it would have been enough if it was just for that). I personally believe its going to be very difficult for jj to replicate that.

I like the distributed nature of git but miss how svn worked to some degree. Generally I agree with you, git works, I read the post and didn't see anything that makes me want to change. The small number of jjites who have been inundating comment sections on this site lately feels like the devotees of Rust (a crap language), podman (which has too many operational inconsistencies) and JetBrains IntelliJ ballywhooers who used to preach IntelliJ's features on every programming related site.

Re: jj – the CLI for Jujutsu

#283

Post by steveklabnik »

SV_BubbleTime wrote: post #253
steveklabnik wrote: post #235

Earlier quoted context omitted.

You're right that, looking solely at `init`, a flag could make sense to choose the backend. The bigger picture here though: `jj git` is the subcommand that prefixes all commands that are git specific, rather than being backend agnostic. There is also `jj git clone`, `jj git fetch`, `jj git push`, etc. For a different backend, say Google's piper backend, there's `jj piper `. This means that backend specific features a…

>There is also `jj git clone`, `jj git fetch`, `jj git push`, etc. If the compatibility isn’t automatic… why would I bother with jj commands here at all? “Git with extra steps”

The on-disk repository compatibility is automatic. But if you're trying to fetch something via a specific protocol, you use the command for the protocol you want to use.

There is no extra step between `git push` and `jj git push`, they're both one step.

Re: jj – the CLI for Jujutsu

#284

Post by sfink »

shermantanktop wrote: post #182
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…

This is me! I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion. Hence I have multiple workspaces, and I shelve changes a lot (IntelliJ. I end up with dirty repos too and that can be painful to cherry-pick from. Sometimes I just create a git patch so I can squirrel the diffs into…

I'm about the same. jj is kind of perfect for that. Example:

# I've finished something significant! Carve it out from the working "change" as its own commit.

    `jj commit --interactive` # aka `jj commit -i` or `jj split`, depending on how you prefer to think of it: making a commit for some work, or splitting a separate commit out of the working change.
# Oops, missed a piece.

    `jj squash --interactive` # aka `jj squash -i`
# Let me look at what's left.

    `jj diff`
# Oh right, I had started working on something else. I could just leave it in the working change, but let me separate it out into its own commit even though it's unfinished, since I can always add pieces to it later.

    `jj commit -i`
# Wait, no, I kind of want it to come before that thing I finished up. Shoot, I messed up.

    `jj undo`
# Let me try that again, this time putting it underneath.

    `jj split -B @-` # aka `jj split --insert-before @-`. @ is the working change, @- is its immediate parent(s), @-- is all grandparents, etc.
# Note that instead of undoing and re-selecting the parts, you could also `jj rebase -r @- -B @--` to reorder. And in practice, you'll often be doing `jj log` to see what things are and using their change ids instead of things like `@--`.

# I also have some logging code I don't need anymore. Let me discard it.

    `jj diffedit`
# Do some more work. I have some additions to that part I thought was done.

    `jj squash -i`
# And some additions to that other part.

    `jj squash -i --into @--`
# etc.

There's a lot more that you could do, but once you internalize the ideas that (1) everything is a commit, and (2) commits (and changes) can have multiple parents thus form a DAG, then almost everything else you want to do becomes an obvious application of a small handful of core commands.

Note: to figure out how to use the built-in diff viewer, you'll need to hover over the menu with the mouse, but you really just need f for fold/unfold and j/k for movement, then space for toggle.

Re: jj – the CLI for Jujutsu

#285

Post by brendoncarroll »

steveklabnik wrote: post #271
brendoncarroll wrote: post #245

Earlier quoted context omitted.

I've heard that jj has support for non-git backends? Can anyone comment on how difficult it would be to add support for another backend, any docs or examples? I have a project[0] that does the large file thing well, but is missing most of the version control porcelain. I've been looking for the path of least resistance to integrate it into something with a larger user base. [0] https://github.com/gotvc/got

To add a new backend, there's a trait that you implement for your backend: https://github.com/jj-vcs/jj/blob/713a0d0898448392d38fdcbaba... I suspect if you came by the jj discord, folks could help you with more detail than that.

Thanks for the link.

It looks like this treats files as blobs just like Git, and trees as single objects which fit in memory. Assuming that is a correct understanding, this core abstraction would need to change to handle large files and directories well.

All the well known version control systems do this though, and it simplifies the system significantly. It's the right model for source code, but it doesn't translate well to arbitrary data.

Re: jj – the CLI for Jujutsu

#286

Post by ersatz-matty »

rasguanabana wrote: post #266
EliasWatson wrote: post #211

Earlier quoted context omitted.

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

> So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone. It’s possible to recover from these with git reflog, though.

`jj undo` compared to what exactly?

Re: jj – the CLI for Jujutsu

#287

Post by nickisnoble »

klauserc wrote: post #247
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!

jj automatically hides "uninteresting" changes. Most of the time, this is good. Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?

Easy: `jj log -n 25`

(Default is 10 iirc, so if you want 15 more... 25)

If you want everything, ever: `jj log -r ::`

Or every ancestor of your current change: `jj log -r ..@`

Re: jj – the CLI for Jujutsu

#290

Post by newsoftheday »

octocop wrote: post #157

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

Agreed and not only that but for any comment on this page which raises a valid exception; there is a cadre of jj devotees ready to counter them if and where they think they can. It feels like someone had a some financial state in brainwashing the world to leave git for jj.
Post reply on HN