4 ms·

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

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. Even though my main work involves quite a lot of annoying rebases which is where JJ really seems to shine. I dunno I guess it's just that a) I've really mastered git and have a deeply-rooted workflow in it and b) despite my project involving annoying rebases, version control still isn't very high on the list of problems I have. So yeah I'm basically bullish on JJ as a technology but I think movement from Git is inevitably gonna be slow and steady.

stouset 1y ago
I'm not entirely sure that "after using it I really like it and I'll switch eventually" is that much of a counterpoint :) What really kept you from staying with it? It does seem like if your workflow involves a lot of nasty rebases you'd reap dividends from something like jj. I was also someone who'd mastered git (hell, I've written a git implementation) so I get having its patterns deeply ingrained.
- bjackman 1y ago
  Yeah I guess it confirms your point in a way too. There's nothing keeping me from switching except the activation energy cost. Almost every aspect of working in my area (Linux kernel) is painful so I'm constantly investing in tooling and workflow stuff. So usually I just don't feel like investing EVEN MORE in the area of tooling that's probably least painful of all. So yeah this is still basically a recommendation for people to try JJ!
sethammons 1y ago
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!
- rfoo 1y ago
  Mainly open source stuff. Chromium, Android, etc.
  - tex0 1y ago
    https://opensource.google/projects https://opensource.google/projects I think all of those are using git and many Gerrit as well.
- bjackman 1y ago
  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...
shaftway 1y ago
> 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.
- steveklabnik 1y ago
  > Does JJ play well with Gerrit? There was a PR for a `jj gerrit` command, but at this point, it's not super needed. Here's the main bug tracking this https://github.com/jj-vcs/jj/issues/4387 https://github.com/jj-vcs/jj/issues/4387 Beyond that, the jj, gerrit, and git butler folks are working together on standardizing the change ID concept so they all work well together without extra tooling. That's going to take a long time though. Think "store the change ID in the commit rather than as a trailer", that kind of thing.
- bjackman 1y ago
  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.

stouset 1y ago

I'm not entirely sure that "after using it I really like it and I'll switch eventually" is that much of a counterpoint :) What really kept you from staying with it? It does seem like if your workflow involves a lot of nasty rebases you'd reap dividends from something like jj. I was also someone who'd mastered git (hell, I've written a git implementation) so I get having its patterns deeply ingrained.

bjackman 1y ago
Yeah I guess it confirms your point in a way too. There's nothing keeping me from switching except the activation energy cost. Almost every aspect of working in my area (Linux kernel) is painful so I'm constantly investing in tooling and workflow stuff. So usually I just don't feel like investing EVEN MORE in the area of tooling that's probably least painful of all. So yeah this is still basically a recommendation for people to try JJ!

sethammons 1y ago

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!

rfoo 1y ago
Mainly open source stuff. Chromium, Android, etc.
- tex0 1y ago
  https://opensource.google/projects https://opensource.google/projects I think all of those are using git and many Gerrit as well.
bjackman 1y ago
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...

shaftway 1y ago

> 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.

steveklabnik 1y ago
> Does JJ play well with Gerrit? There was a PR for a `jj gerrit` command, but at this point, it's not super needed. Here's the main bug tracking this https://github.com/jj-vcs/jj/issues/4387 https://github.com/jj-vcs/jj/issues/4387 Beyond that, the jj, gerrit, and git butler folks are working together on standardizing the change ID concept so they all work well together without extra tooling. That's going to take a long time though. Think "store the change ID in the commit rather than as a trailer", that kind of thing.
bjackman 1y ago
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.