Live data from Hacker News

Jujutsu for busy devs

maddie.wtf

121–130 of 552 posts

Re: Jujutsu for busy devs

#121
post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

I tried it and didn't switch. The funny thing is I immediately recognised that it was forcing me to use git in basically the same way I use it anyway. I have more than 15 years experience with git at this point. I never had to do the "delete repo and reclone" thing after the first year. In other words, I actually understand git, so I don't really need Jujutsu.

I also already use very good tooling for git, namely Magit. IMO Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all. It's quite remarkable.

Maybe I should recommend jj to some of my colleagues, though. Trouble is I'm already on the hook for helping them with git, but I don't have the experience with jj.

Re: Jujutsu for busy devs

#122
post #44

Earlier quoted context omitted.

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

I relish the day I get to use bisect. It's like, finally I get to use all this version data I've been collecting. I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.

It’s really nice to use the —-first-parent flag with bisect.

Re: Jujutsu for busy devs

#123
post #44
post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

Bisect is a wonderful feature. Git is full of tedium and frustration, bisect is not part of that.

Re: Jujutsu for busy devs

#124
post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

"You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. "

Reporting in. Doesn't mean I will not end up with jj eventually, but so far I always went back to git after a while.

For me it is the staging area and the workflow it allows. Most people hate it and love jj because it does away with it. That is just not me. I don't see the staging area as a hack that was necessary to overcome some superfluous technical limitations but as a workflow tool.

Could I change my ways? Sure. jj just did not provide enough benefit for me so far to do it, but we will see. I am still open to give jj another try some day.

Re: Jujutsu for busy devs

#125
post #71

Earlier quoted context omitted.

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode be…

Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.

I think most people would use a logging library (maybe at the "trace" level) at that point.

Re: Jujutsu for busy devs

#126

I legit ask myself how many folks avoid Github Desktop for some dogmatic reasoning equivalent to "having an UI makes it worse", when it does the core of common flows extremely easily and clear. To be clear where it ties to this post: it makes git far more convenient with nearly 0 learning curve.

When I was first learning coding, git, etc. and had no clue how git worked I downloaded GitHub desktop and used that. It's true that I was much younger and less knowledgeable then so it's possible that's influencing me but man when you actually understand git the cli just feels so much smoother, cleaner, and faster. It really doesn't take much dedicated to time to learn the top 5 commands you'll use 95% of the time and if you don't know git currently I think it's probably one of the most leveraged ways you can spend your time.

Re: Jujutsu for busy devs

#127
post #81

Earlier quoted context omitted.

If you hardcode the background to a fixed color, the 4-bit palette for foreground colors is generally to be avoided -- instead, use the 8-bit (256 color) or bigger palettes.

I don't control these applications.

If I understand correctly, you're in the situation where you've chosen your 4-bit colors so that they render properly on an application which (incorrectly) uses an 8-bit background color but a 4-bit foreground color, and also that the colors don't render well on the default background that's part of the same 4-bit palette.

I think you'd be a great candidate for jj's ability to customize colors.

Re: Jujutsu for busy devs

#128
post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

I tried it and I went back to git. I know how git works though. I don't put much stock into your 'anecdata'

Re: Jujutsu for busy devs

#129

Earlier quoted context omitted.

If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).

What is the "right" way to do it then? Also probably most of us are stuck with whatever git*.com supports anyways...

Use `--update-refs`.

Think about the word "branch". If you have a linear sequence of commits that's one branch by definition. But you go and label the middle of that branch as branches too and then get annoyed when git, you know, does some branching there.

Re: Jujutsu for busy devs

#130
post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

I tried it and didn't switch. The funny thing is I immediately recognised that it was forcing me to use git in basically the same way I use it anyway. I have more than 15 years experience with git at this point. I never had to do the "delete repo and reclone" thing after the first year. In other words, I actually understand git, so I don't really need Jujutsu. I also already use very good tooling for git, namely Magi…

> In other words, I actually understand git, so I don't really need Jujutsu.

This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj obsolete.

I am (or was) a git expert. I’ve used it since pre-GitHub. I’ve written a git implementation. I know (or knew) the interface inside and out. I haven’t deleted and re-cloned a repo in as long as I can remember.

jj is still leagues better. Things I want to do and know how to do in git are dramatically faster and easier. They require less mental overhead. They’re less error prone. And I get superpowers with workflows that are super useful but wildly impractical in git.

This isn’t even really opinion at this point. Any task you can give me in git, I can with almost near certainty give you a shorter and more elegant alternative with jj that is an intuitive and obvious interaction with its core primitives.

A month ago our company split off a division. They needed to take a specific repo and sanitize out all of the parts that aren’t relevant to the new company, going back to the beginning of its commit history. You can do this with git. It wouldn’t be fun. I’d have to spend a lot of time reading the filter-branch manpage, and people have written countless wrappers of varying quality that try and make it a bit more ergonomic.

It took me like ten minutes to come up with:

    declare -rA paths=(
        …
    )

    # for every commit that touched a file
    # we want to excise
    for id in "$(
        jj log \
            --revisions '..' \
            --no-graph \
            --template 'change_id ++ "\n"' \
            "${paths[@]}"
    )"; do
        # restore those paths’ contents from the
        # the empty root commit; this happens 
        # entirely in-memory without having to check
        # out each revision into the working copy to
        # do file operations so it is FAST
        jj restore \
            --from 'root()' \
            --to "${id}" \
            "${paths[@]}"
    done

    # remove any commits that are now empty
    # (except for the implicit root commit)
    jj abandon \
        --revisions 'empty() ~ root()'
Three dumb, simple commands that I already use every day: list some commits, copy file contents from one commit into another, and remove some commits from the tree.

Not only was this more or less obvious to do, but it was exceedingly fast to perform on a pretty highly-trafficked repo due to not having to thrash around in the working directory with checkouts.

> Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all.

jj is more powerful than git. It’s not simply a dumbed-down alternative. By having a more carefully chosen set of primitives that compose better, you gain a lot of abilities that are technically possible with git but never used in practice due to the complexity. The above is IMO a fantastic example of how and why.

And you can still do all the normal git things too.

Post reply on HN