Because it's usually a mistake. Think cutting one of your fingers or running off of a cliff, sometimes it's intentional but in most cases it's likely a mistake.
It's not actually disallowed as there can be the odd use for it[0], just not allowed by default anymore (since Git 2.9: https://github.com/git/git/blob/master/Documentation/RelNote...).
[0] as the article shows, the linux kernel does seem to have 2, though in both case it could have been done otherwise e.g. by rewriting the history of the external development to be inscribed in the normal kernel history
It just seems like such a useless case to treat specially; merging a branch that branched off from the first commit in the repository is equally likely to be a mistake, but the check doesn't cover it. It feels like a lot of effort for a completely minor case that doesn't even cause a significant problem when it happens.
It's both way less likely to happen (getting a handle on the first commit of a repository really is not something you can do by mistake) and way less inconvenient when it does happen (because merging forked branches is a perfectly normal operation and it doesn't really matter how much the branches have diverged).
> It feels like a lot of effort
It is not a lot of effort: it's just adding a check when merge-base returns nothing.
> for a completely minor case that doesn't even cause a significant problem when it happens.
It completely fuck up diff views of the merge commit.
Why is two branches that diverge after the initial readme commit so much easier than two branches that diverge from the start? Why doesn't it just treat it the same way (as if the empty repo state was a commit that's the merge base)?
> It completely fuck up diff views of the merge commit.
Same question as above - why is the diff so different in that case?
> I'm very annoyed, because while the multi-root situation can be useful, it can also be confusing as hell. It can cause bisection problems, and it can just cause people to go "WTF?"
http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01890.html
I guess history visualization tools would have a hard time with it as well. But in general, you normally start writing your changes from an existing commit anyways so why not branch from that?
The case where that feature can legitimately be used is systems which started as completely separate (possibly with no idea that they even could get merged ever) and then got integrated e.g. TFA provides the example of btrfs which started development out of tree.
In that case, just copying the project you're importing is obviously unacceptable (as it loses all history), and rewriting the entire history in order to "rebase" it has its own issues e.g. conflicts with existing files, loss of traceability since the commits get rewritten entirely and their hashes change, …
So while it has its own issues (which you note), there are situations where merging a separate root does have advantages which outweigh the issues. The other alternatives (e.g. submodules) but all of them have their own drawbacks.
I had a web design client that decided to move to a platform with integrated Git deployment, for a WordPress site that was already developed on a different platform with it's own Git deployment and all of the development history on there. The new platform had a different way of getting configuration, and a different set of platform integration plugins. So I couldn't just force-push the old platform's Git history; I actually did need to do a divergent-history merge in this case and resolve the result in the new platform's favor.
I assumed the warning meant that you couldn't do it, or that it would be super error-prone, or something; but it turns out that it worked perfectly fine with no problems (aside from standard Git merge conflict resolution).
But it's something that you only have to do rarely. Projects merging is far from the normal PR after all, and it makes sense to give a warning in such a situation.