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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

541–550 of 552 posts

Re: Jujutsu for busy devs

#541

Post by Filligree »

nchmy wrote: post #516
icorbrey wrote: post #477

Earlier quoted context omitted.

Megamerges are awesome, but what really makes them magical is when you start using `jj absorb`, which automatically splits and squashes your commit down to the nearest unambiguous commits and leaves anything that doesn't have an obvious place to live

I've been trying absorb recently and have found it rarely does anything and I just resort to squashes. Any idea what might be going on?

Absorb:

- Will not rewrite an immutable commit, of course. (Though you can tell it to, and for my personal repositories I sometimes actually set immutable() = root().)

- Will not do anything to diffs if it's uncertain where they should go, either because that file wasn't edited in a previous mutable commit, or because it was edited in multiple sibling/cousin commits. The latter is likely to happen with mega-merges.

You can use --into to restrict the set of target commits, if you already know what feature branch you're updating.

Re: Jujutsu for busy devs

#542

Post by martinvonz »

therealpygon wrote: post #540
stouset wrote: post #154

Earlier quoted context omitted.

For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated chan…

To be clear, I haven’t used jj so please correct any misundersrandings. I hear you and agree that smaller PRs are definitely easier to understand. On the flip side, it sounds like jj just trades large PRs for lots and lots of smaller, independent PRs that are seemingly unrelated despite all belonging to the same change? I wouldn’t see that as better because, on face, it would sound like far more opportunity for chang…

I don't know why you think jj makes you produce many little commits. Are you thinking about the automatic snapshotting of the working copy? That amends (replaces) your previous commit, so you won't end up with a long chain of commits.

It's probably easiest to understand by just trying it. It can be used with regular Git repos.

Re: Jujutsu for busy devs

#543

Post by dmsnell »

sshine wrote: post #532
dmsnell wrote: post #355

Earlier quoted context omitted.

You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message. git rebase -i --rebase-merges --keep-base trunk This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvem…

That’s great advice, thanks for sharing --update-refs! But I don’t see how that removes the usefulness of fixup commits, only that you can do them across stacked branches with ease. But you’re saying I don’t need the particular hash of the parent, I can just rebase all the way back to main/trunk each time. That’s a good point! I think I’m still saving time by fixup, it was the second hash lookup I wasn’t happy with.…

You understand it correctly: it doesn’t remove any value from fixup; instead it just means you can fixup to whatever and move the commit visually to where you want it — doesn’t have to be the main/trunk branch, and you can do it whenever is convenient.

That’s where I made the comment about not actually running fixup. Instead of claiming to fix a SHA, I leave myself a note like “fix tests” so I can move it appropriately even if I get distracted for a few days

Re: Jujutsu for busy devs

#544

Post by bjackman »

shaftway wrote: post #421
bjackman wrote: post #45

Earlier quoted context omitted.

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me.…

> I don't do my day-to-day work in the monorepo Is this one of the repos that uses Gerrit? Does JJ play well with Gerrit? IIRC Gerrit was super picky about amending commits and I was worried JJ's laissez faire attitude about creating git commits on demand wouldn't jive well.

I haven't used JJ with the git backend so there may be something I'm missing here, but I don't see any reason they wouldn't play nicely. (I use Gerrit daily with pain git).

JJ does create commits without you explicitly asking but you do still have direct and fine grained control over it. It's not magic it's just that it's occasionally implicit. And squashing and splitting is nice and easy.

Re: Jujutsu for busy devs

#545

Post by bjackman »

sethammons wrote: post #176
bjackman wrote: post #45

Earlier quoted context omitted.

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me.…

Curious, I was under the impression that Google was all a monorepo, but your phrasing suggests that there are others. As my company is pushing for a monorepo, I'd love to know what causes someone at big G to not be in the monorepo. Thanks for any insights you can help me with!

Yeah as others mentioned it's really all about open source.

If your project is open source but still interacts with the main body of Google code in a significant way, you can still be in the monorepo and then mirror it to Git via Copybara (or you can work primarily in Git and then mirror to the monorepo via Copybara).

The most common case of that is libraries that get imported into server binaries. There's a whole section of the monorepo for open source code, with special rules and processes around it.

But a that has setup and friction costs so it's only worth it if you see a pretty significant upside.

For stuff that's pretty standalone there's no point. Classic cases are Chromium and Go. Then of course there's Google's various operating systems...

Re: Jujutsu for busy devs

#546

Post by globnomulous »

stouset wrote: post #404
UK-Al05 wrote: post #379

Earlier quoted context omitted.

Reviewers don't want to navigate 33 tiny PRS either. The best way of getting changes is through is simply sitting down and talking with the reviewer. Most of these small PRS, splitting things, creating elaborate stacking systems are just technology hacks around a social/process problem. I've seen people make more of a mess trying to split pr's up where they are so fine grained its silly and actually had dependencies…

> Reviewers don't want to navigate 33 tiny PRS either. As opposed to one 33-change PR? Yes, absolutely yes they do. I probably don’t have time to review a giant PR like that. If I do, I feel guilty asking for fixed in one part when 31 of the changes are great. Why are we holding up all these improvements for one or two small concerns? We can merge and just fix those later. Except that never happens. I probably have t…

> one-liners

One commit for a single line? I can't imagine developing software this way. Fixing bugs? Sure. Altering this or that in a well-established, mature codebase? Probably. For features, I don't see how it's possible.

Re: Jujutsu for busy devs

#547

Post by globnomulous »

normie3000 wrote: post #313
nchmy wrote: post #287

Earlier quoted context omitted.

Jj makes this effort vastly easier. Nearly frictionless.

Great. As I said elsewhere on this story, I'll suggest jj to colleagues who struggle with git.

Yeah, I don't get it. Maybe I'm just confused but the git mental model has never struck me as complex or confusing.

jujutsu also seems like a poor fit for large monorepos repos (particularly ones that use git hooks). The expense of certain git operations increases quadratically with the size of the repo. A repo doesn't need to be terribly large for `git status` to require 5-6 seconds. (God bless the man who added scalar and sparse checkout to git.)

The absolute last thing I want is a tool that's doing more with git -- creating commits, branches, checking things out, rebasing, or doing anything that requires a git-status check.

Re: Jujutsu for busy devs

#548

Post by raylu »

resonious wrote: post #108
stouset wrote: 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 used jj for several months, then eventually went back to git. The biggest killer was performance. jj operations took several seconds for me, whereas git is instantaneous no matter how big the project. Maybe this is fixed now. But also honestly I felt like there was a bit more mental burden to using jj. When I switched back to git, it was like a weight off my shoulders. Maybe that's just due to the decade of constan…

I ran into this at first on a large-ish repo. watchman fixed it: https://jj-vcs.github.io/jj/latest/config/#filesystem-monito...

Re: Jujutsu for busy devs

#549

Post by raylu »

Too wrote: post #339
amomchilov wrote: post #312

Earlier quoted context omitted.

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews. Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong. One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly a…

`git rebase -i` lets you reorder one branch of commits easily

in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases

one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)

Re: Jujutsu for busy devs

#550

Post by raylu »

alexjplant wrote: post #431
killerstorm wrote: post #292

Earlier quoted context omitted.

If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.

> A lot of people are religious about rebasing Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in t…

wait what?

bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear

Post reply on HN