I find git conceptually simpler, but honestly git and mercurial are pretty close to each other. I've been giving some thought to Fossil recently and it really seems like the industry missed an opportunity to question some assumptions and biases about what our tools should provide. For instance, neither mercurial or git contain issue/bug trackers, but Fossil does.
> For instance, neither mercurial or git contain issue/bug trackers, but Fossil does.
I’m glad git doesn’t. It’s a separate concern and breaks the “do one thing, do it well” UNIX philiosophy.
People can’t agree on a schema for issues/bug-trackers as it is, and you’ll have the ISO 9001-compliant folks who feel compelled to have 150 different hierarchical fields and 20 different issue classes with the Github issue pragmatists happy with only using non-hierarchical non-namespace tags. You could accommodate them all by using a schemaless or custom schema support, but then you’ll have people fighting over how to implement custom schemas, and then having to get people to work on building that feature.
It would also be inappropriate for security-sensitive issues or other cases where compartmentalising information is necessary. (And encrypting the data doesn’t help once the key gets leaked)
If you really want bug-tracking in-repo, you can still do that with a Text-file tree or Sqlite DB in a separate branch (probably a good idea to have a separate checkout to avoid expensive `git checkouts` when the entire tree changes.
