[IshKebab]

Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better):

* Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy).

* Large files. LFS is a PoC-level hack; not a proper solution.

* Conflict resolution. The default diff algorithm is very dumb, and even with `zdiff3` it doesn't quite give you enough information to easily resolve all conflicts.

[dig1]

Git is very good with large repos, but the monorepo concept doesn't fit the git model. Monorepo is a bad idea with the current DVCS-es unless you use custom tooling. My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow.

If you want monorepo, use Perforce or SVN, but good luck with the speed ;)

[IshKebab]

> Git is very good with large repos

Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it.

> My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow.

Rubbish, it's nothing to do with wanting to be Google-scale. In fact being Google-scale makes a monorepo more difficult and require custom tooling.

The reason people like monorepos is because they don't have the downsides of multirepos:

* Cross-repo changes are very difficult to do and even harder to test.

* Testing code becomes very difficult. For example if you update a library that's in one repo, how do you test all the things that depend on it? Very difficult with multirepos, trivial with monorepos.

* Git's support for submodules is really bad.

The downside of monorepos is that they are big and slow, but they work fine as long as you aren't Google scale.

[dig1]

> Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it.

Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine.

> The reason people like monorepos is because they don't have the downsides of multirepos:

The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline. But, to each their own.

[IshKebab]

> Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine.

Not really; it just means you misunderstood what I meant by "large projects". The Linux kernel is not nearly as large as most company codebases.

> The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline.

Sounds like you just don't have any experience of this sort of thing so don't appreciate the problems. You update the library in one repo and test it in another because that other repo is using the library. You want to make sure your library update doesn't break it.

If you don't test all of the dependants of your library then you're massively increasing the risk of breakage (plus all the other downsides) just so you can use separate repos. That isn't worth it.

[capitainenemo]

I definitely feel the large file support in Mercurial is less bolted-on. My personal favourite mercurial gui features that I hope make it into git or a mercurial using a git data store are:

  phases
  revsets (query language for revisions, they also have filesets for the files)
  hg grep --diff
  hg fa --deleted
  hg absorb