I see a future in jj

> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size.

I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?

The intention with this is to also deprecate the Perforce fork, in my understanding.

But yeah, it's been a lot. Frankly even harder to keep track of from the outside!

I don't think this is quite right.

The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).

I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.

What was the reason for using Mercurial?

Why did Google decide to choose Mercurial? Based on what I read the main reason was that the mercurial dev team was willing to prioritize features needed for Google to add custom extensions to support its monorepo, and the git dev team wasn't going to reprioritize just for the sake of Google.

I think you’re confusing Google with Facebook.

Yes, that's correct. Another reason was that Mercurial is easier to customize because it's written in Python so we could sometimes just replace whatever we needed without needing much changes from Mercurial itself.

Yet another reason is that the .git directory is considered a documented API and several other tools and libraries depend on it (e.g. JGit and libgit2). So any new features for Google would need to be made to those tools too if we wanted things built on them to work.

We also consider Mercurial to have better UX.

j2kun seems to be a googler so I don't think so, but it's true that Facebook also went with Mercurial. I suspect it was for similar reasons.

Ahh. It sounded like a repeat of https://graphite.dev/blog/why-facebook-doesnt-use-git but maybe it did happen for both companies! They’d obviously be having similar issues. Thanks :)

I hope it sticks around so that I can use the same workflow at work and home. I'm really enjoying how fast all the jj operations are compared to mercurial.

I can second that the aforementioned reasons are true. The funny difference is that Google employs the primary git maintainer. Git has a lot of customers though so it rightfully is very conservative with development.

I used git5 from when I started in 2011 to when I left in 2017.

I'm going back starting on monday, so I'm curious to try out jj.

In the past 10 years it's all been github and gitlab, and their code review tools are so painful, specifically w.r.t. tracking discussions across revisions. I never felt excited to try out jj because I was afraid it would that situation even worse.

It was deprecated in 2015 iirc

In fairness that's not much different from any other internal Google tool. Those don't often have a two-digit years shelf life.

I'll venture that jj is there to stay, however. If not at Google, then in general. It's just too much of a quantum leap. I think I've finally identified what about it sits so right with me: a change's identity is preserved through its revisions. In bare git, after a rebase or an amend, you get a wholly different commit that just happens to have a similar content.

Mind you, I'll also venture that jj will remain based on git as its storage backend, despite its stated goal otherwise. Git's internals are just too good at what they do to make it worthwhile to replace them.