3 ms·

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind.

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? None of this makes any sense to me. > Local branch names are optional. As are they in git, just hang out with a detached HEAD. > There is no staging area. Practically the entire world sadly invokes `git commit -a` anyways and you still have to add untracked files. Neat project but I don't get what this is solving for.

arxanas 4y ago
A lot of the important work is on back-end scaling for a centralized repository. Example: the segmented changelog allows answering merge-base queries in ~O(log n) time and very quickly in practice; these queries need to happen all the time as part of handling merges on the server-side. You get the front-end, a streamlined interface derived from Mercurial, for "free" as part of the open-sourcing.
- xyzzy_plugh 4y ago
  But this centralized repository isn't available yet, so I cannot evaluate it. And the problems you describe aren't really relevant outside a monorepo or low-volume repositories, of which the vast majority of open source code falls in. I much prefer the ability to clone an entire repository and be able to make changes in a distributed manner. If this is for companies who aspire to have Google or Meta scale problems then this sure is a weird way to advertise it.
deleted 4y ago
[deleted]
sfink 4y ago
> Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? But this is mercurial. Or rather, it's mercurial rebased on top of the git data store, and it's a fork with breaking changes so it has a different name. I do agree that the requirement to be online gives me pause. But I guess I don't know how much of a problem that would be in practice, since there's a mystery subset of functionality that works disconnected. > Neat project but I don't get what this is solving for. For us external people, it seems like it's mostly for using the hg interface with a github-hosted repo. The internal reason appears to be scalability to massive monorepos. Since I much prefer the hg interface to the git interface, I'm good with both of those motivations.
- alwillis 4y ago
  >Since I much prefer the hg interface to the git interface, I'm good with both of those motivations. Same.

arxanas 4y ago

A lot of the important work is on back-end scaling for a centralized repository. Example: the segmented changelog allows answering merge-base queries in ~O(log n) time and very quickly in practice; these queries need to happen all the time as part of handling merges on the server-side. You get the front-end, a streamlined interface derived from Mercurial, for "free" as part of the open-sourcing.

xyzzy_plugh 4y ago
But this centralized repository isn't available yet, so I cannot evaluate it. And the problems you describe aren't really relevant outside a monorepo or low-volume repositories, of which the vast majority of open source code falls in. I much prefer the ability to clone an entire repository and be able to make changes in a distributed manner. If this is for companies who aspire to have Google or Meta scale problems then this sure is a weird way to advertise it.

deleted 4y ago

[deleted]

sfink 4y ago

> Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? But this is mercurial. Or rather, it's mercurial rebased on top of the git data store, and it's a fork with breaking changes so it has a different name. I do agree that the requirement to be online gives me pause. But I guess I don't know how much of a problem that would be in practice, since there's a mystery subset of functionality that works disconnected. > Neat project but I don't get what this is solving for. For us external people, it seems like it's mostly for using the hg interface with a github-hosted repo. The internal reason appears to be scalability to massive monorepos. Since I much prefer the hg interface to the git interface, I'm good with both of those motivations.

alwillis 4y ago
>Since I much prefer the hg interface to the git interface, I'm good with both of those motivations. Same.