Hi Richard, On Wed, 2 Dec 2020, Kerry, Richard wrote: > The Story > - - - - - - - - > My project, "L", has two branches "L1" and "L2". It was developed as L1 > for a long period, then a branch, L2, was made and further development > done on that. Since the branch there has been further development on > L1. > > A-B-C-D-E-F-G-H > \ > J-K-L-M > > (That's supposed to show J branching off D. I'm writing this with > proportional spacing so it may look different on receipt) > > > The Reality > - - - - - - - - - > L was developed in CVS as its trunk. That is what I am now referring to as L1. > A-B-C-D-E-F-G-H > > At some point a snapshot was taken and put into Subversion. That is what I am now referring to as L2. > It is either > D-J-K-L-M > Or, more likely, just > J-K-L-M > (If some work was done on the snapshot before it was used to start the > new project in SVN, which I think it was) > > L2 has been converted to git using git's built-in Subversion handling. > I have a backup of the CVS repository for L1 and I can easily convert it > to git using cvs2git. > > What I would like to do is to merge these two branches into a single git > repo. Specifically, to insert L1 into the existing git repo which is > currently only L2. > > (The subversion server no longer exists, and I don't have easy access to > the repository backup, and there may have been work done since the > import. I have a full backup of the CVS repository and I can easily > convert it to git using cvs2git, with any extra parameters required.) > > 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). > > cvs2git works by generating fast-import scripts, so I can intercept the > result of that and edit the import scripts if necessary. I can even > dump L2 and rebuild everything using fast-import if that's the best > option. Maybe L2 needs to be imported into L1 after generating a tag in > L1 to indicate where the branch happens? That seems to be a more > complex work-flow for this task - I would hope to be able to do minor > manipulations of branches and only one fast-import (ie L1). > > > So, I'm still looking to see if I can find any other way of wrangling > branches to make this happen, but I'd appreciate anyone else's advice on > how to achieve my merger. If I were you, I would use `git replace` to pretend that the `D` in your `L2` history has the `C` in your `L1` history as parent: git replace --graft <D-as-in-L2> <C> Note that this is a local-only operation. Even if you push, the remote repository won't know that you grafted L2 onto L1 in your local worktree. Ciao, Johannes
