Paraphrasing: > 1. Git data model only lets you see ancestor commits, not descendants. Maintainer needs to find descendents. It's technically true about git's

Paraphrasing: > 1. Git data model only lets you see ancestor commits, not descendants. Maintainer needs to find descendents. It's technically true about git's data model, but it's not too hard to reconstruct forward history based on all refs (branches for this purpose). (see "git rev-list"). They don't justify the use-case that demands this information be trivially available, and I've never personally needed it, so I find this a weak argument. I have needed to find what branches contained a given commit (either a regression or a bugfix), and that's available with "git branch --contains <SHA>" > 2. The mental model of git is complex (working dir, index, local head, local copy of remote head, remote head) Granted. It's especially always complicated trying to explain to beginners the distinction between local head, local copy of remote head, and remote head. Though it makes sense to me when working out technical implications of git's distributed data model, it's obvious that many users are overwhelmed. (I think the mental model is actually great, but I won't impose my opinion on others) > 3. Fossil's branch history display is better than GitHub's, and git doesn't tell you if a branch has been merged No mention of "git log --graph" (or any GUI alternative) which goes a long way of solving their complaint. I agree that GitHub's graphless history is frustrating, but that's a GitHub issue, not Git. However, Git does "swallow" merged branches, as the merge commit may be a property of the receiver branch, not the original branch (depending on your development model). Git doesn't enforce something there, so I agree with the issue. > 4. Git lacks essential wiki/bug-tracking. If you use 3rd-party tool for these, they're centralized Granted, though I'm not quite convinced in how "essential" it is to have that tightly integrated in the version control system, and thus have it distributed, but that's probably an artifact of me being used to existing git-based systems. A counterpoint to this is that Git (now) has a healthy ecosystem of alternatives for you to choose from. If you're not satisfied with Fossil's offering, how easy is it to change? > 5. Git requires administrative support for the extra web tools that Fossil otherwise integrates This follows from the previous point, so granted. I'd add to this that Git lacks a good access-control/code-review system, hence the rise of so many alternative portals (GitHub/Gitlab, Gerrit...) > 6. No-one really understands git [w/ XKCD link] Now you're just trolling. Overall, I'm surprised at how many points I actually agree with the author(s), but the main difference is that git purposefully aims at a more limited feature-set that excludes project-management (ie wiki/bugtracking), which I guess is the consequence of its Torvalds/kernel-originated development history.