The docs of `git merge` do indicate acceptably clearly that multiple commit-ish can be given.
I expect it's really more that "octopus" merge are usually of limited use, most projects are not structured as a distributed "tree of trees" the way the linux kernel is, where merging multiple downstreams regularly is a normal workflow and thus octopus merges make a lot of sense.
SoC is mostly used for: within one packaging, not for: on the same silicon. For example: if you open the esp32 or 8266 you will see multiple chips even with their own packaging inside.
Is there some practice around making sure the octopus-merged branches concern separate files (have no conflicts)? Imagine resolving a 12-way merge conflict. Yeesh.
Octopus merge will fail if there are any conflicts that require manual resolution [0], but there are ways around this like manually creating the commit. Raymond Chen had a has some interesting posts using this to split files while preserving blame history [1] (the manual method is linked at the beginning).
> 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?
> 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?"
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?
> 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.
It doesn't seem fundamentally harder than pretending all of the changes happened in a different directory, and then that directory got moved from being a sibling to a subdirectory of the nominal project root.
it's a problem in the git model, since all the commit hashes would change. that means that all existing references become invalid, including emails, commit messages, and pull requests.
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).
I've done it a few times, and it worked perfectly well each time. Here [0] for instance, a couple repos had evolved to be codependent, and so we combined them into one.
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.
Joys of having Linux and git both written+managed by Torvalds:), although I do wonder if that points to to a shortfall in docs/UI.