> google employed the folks who wrote the git clients and it was always technically possible to have implemented the monorepo with a git client
I think we're talking past each other a bit here. Piper's implementation could have been git-compatible originally yes (I think this is what you're saying?). The thing this article complains about is the turndown of the unofficial, unstaffed (20% at best) git-wrapper client around piper. That was a hacky not-fully-git-like but still well loved (I used it for a while!) tool. Doing it right would have been a huge undertaking and, as I understand, would have required building a totally new thing, while mercurial was hackable and extensible and could be used as a base.
I'm not talking about the git wrapper. I'm talking about native "git talks to piper" support, with sparse (read-through) for parts of the tree that aren't checked out. It wouldn't have been a huge undertaking, that was never the case. It's what's documented, but it wasn't actually truth. I worked with the individuals involved at the time the decisions were made and the rationale was much weaker than you think.
I think we're talking past each other a bit here. Piper's implementation could have been git-compatible originally yes (I think this is what you're saying?). The thing this article complains about is the turndown of the unofficial, unstaffed (20% at best) git-wrapper client around piper. That was a hacky not-fully-git-like but still well loved (I used it for a while!) tool. Doing it right would have been a huge undertaking and, as I understand, would have required building a totally new thing, while mercurial was hackable and extensible and could be used as a base.