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