On Wed, Dec 02 2020, Kerry, Richard wrote: > I've read up on merging repositories and I can easily get L1 into the > same repo as L2, as a separate line of development. However, merging > it is not the right thing to do, as that leaves me with L1 and L2 > having separate starting points, with a merge leading to there being > only one head. That's the opposite of what I want - I want to keep > one starting point (that of L1), and branch L2 off it (with L2 ending > up as master). I've brought in existing repos into other repos like what you describe you shouldn't be doing, "git merge --allow-unrelated-histories" exists for a reason, you can just use it. I do think you're starting from the wrong starting point though, maybe not in your thinking, but your post just says you want to combine these, and how to do it. The reason I've done this in the past is for some practical reason. E.g. you might want to arrange it so a "git blame" or "git log" on a file traverses down the right path & history, or to be able to refer to commits by SHA1. Depending on what you actually want to with the end result merging or using grafts might not be the best thing to do. E.g. a perfectly OK thing in some cases is to just have a side-repo somewhere to keep the old history, you can add it as a remote to do some ad-hoc inspection, but never need to push a merger of the two to the current active repo.
