3 ms·

1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are par

by kyrra 10y ago

1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0]. 2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more complicated as all the implementations need to add them before they can be more widely used. Mercurial has one implementation that everyone uses. So new features are easier to add. 3) The .git structure is simple, which is great, but it's become the API for git in a way. While mercurial explicitly says you should never rely on the structure of the .hg directory. If you want to interact with the .hg dir from other software, you should either issue 'hg' command or start up a command server[1] to talk with it. So it creates a cleaner API barrier. Because of this, the Mercurial team can make changes to the .hg dir to better serve different needs (like those of a mono-repo), without breaking the world. [0] https://bitbucket.org/Google/narrowhg https://bitbucket.org/Google/narrowhg [1] https://www.mercurial-scm.org/wiki/CommandServer https://www.mercurial-scm.org/wiki/CommandServer

avar 10y ago
The .git file format has also changed multiple times, packed refs, multiple pack file formats etc. There's even WIP ref backends now which store the whole thing in some embedded database format.
- alblue 10y ago
  There is no ".git" file. It's a directory with a lot of files. Some of the packing has been storage optimisations but the logical model (objects identified by hash) has remained the same throughout. The nice thing about this is you can present the same logical model while being flexible about the way that model is persisted, unlike Mercurial which has a fixed file format upon which operations are based.
bedros 10y ago
narrowhg looks like a good replacement for subrepo, thanks for the tip
- Mathiasdm 10y ago
  Keep in mind that narrowhg is extremely experimental!
s_kilk 10y ago
Mercurial also has a proper plugin architecture, which means that new features can be developed in the wild as needs arise, and then either become widely used or rolled into the standard distribution.

by kyrra 10y ago

avar 10y ago

The .git file format has also changed multiple times, packed refs, multiple pack file formats etc. There's even WIP ref backends now which store the whole thing in some embedded database format.

alblue 10y ago
There is no ".git" file. It's a directory with a lot of files. Some of the packing has been storage optimisations but the logical model (objects identified by hash) has remained the same throughout. The nice thing about this is you can present the same logical model while being flexible about the way that model is persisted, unlike Mercurial which has a fixed file format upon which operations are based.

bedros 10y ago

narrowhg looks like a good replacement for subrepo, thanks for the tip

Mathiasdm 10y ago
Keep in mind that narrowhg is extremely experimental!

s_kilk 10y ago

Mercurial also has a proper plugin architecture, which means that new features can be developed in the wild as needs arise, and then either become widely used or rolled into the standard distribution.