> So why disallow merging unrelated histories? Does it cause any actual problems?
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.
[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
> 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 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 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'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.
> 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).
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?
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