Stitching together two split segments from svn

> I have a project whose history is stored in two separate svn
> repositories.  The first repository I kept privately during initial
> development, the second started when I posted it publicly and does not
> have the history of the first.  I am trying to reunite them under git.
>  The development of the first was linear, so after using git svn, the
> history looks like:
> 
>  a - b - ... - c - d = HEAD (old repository)
> 
> and the second has one branch "ffa":
> 
> (new repository)
>  T - d - e - ... - f - g - h - ... - j   master
>                       \
>                        k - l - .... - m  ffa
> 
> Note that T is the "trunk" initial commit on the svn repo that has no
> files.  The second commit d is identical to the HEAD of old, as
> verified by git diff.
> However, when I remote add these two into a single repository, they
> show up as two detached chains, with no connection between them.  I
> thought git rebase would reconnect them.  However, when I do that on
> each branch (master and ffa), I get the following:
> 
>  a - b - ... - c - d - e - ... - f - g - h - ... - j   master
>                       \
>                        e - ... -f - g - k - l - .... - m  ffa
> 
> instead of what I would like
> 
>  a - b - ... - c - d - e - ... - f - g - h - ... - j   master
>                                      \
>                                       k - l - .... - m  ffa
> 
> That is to say, those commits from the new repository that have a
> common history for the two branches are duplicated.  The commits are
> listed separately and have different SHA IDs, but they are clearly the
> same commits (same comments, same svn version number).  Is there any
> way to do what I want?  Really, all I want to do is change the parent
> of "e" to be the HEAD of the old repository.

> "Liam Healy" <lnp@healy.washington.dc.us> writes:
>
>> I have a project whose history is stored in two separate svn
>> repositories.  The first repository I kept privately during initial
>> development, the second started when I posted it publicly and does not
>> have the history of the first.  I am trying to reunite them under git.
>>  The development of the first was linear, so after using git svn, the
>> history looks like:
>>
>>  a - b - ... - c - d = HEAD (old repository)
>>
>> and the second has one branch "ffa":
>>
>> (new repository)
>>  T - d - e - ... - f - g - h - ... - j   master
>>                       \
>>                        k - l - .... - m  ffa
>>
>> Note that T is the "trunk" initial commit on the svn repo that has no
>> files.  The second commit d is identical to the HEAD of old, as
>> verified by git diff.
>> However, when I remote add these two into a single repository, they
>> show up as two detached chains, with no connection between them.  I
>> thought git rebase would reconnect them.  However, when I do that on
>> each branch (master and ffa), I get the following:
>>
>>  a - b - ... - c - d - e - ... - f - g - h - ... - j   master
>>                       \
>>                        e - ... -f - g - k - l - .... - m  ffa
>>
>> instead of what I would like
>>
>>  a - b - ... - c - d - e - ... - f - g - h - ... - j   master
>>                                      \
>>                                       k - l - .... - m  ffa
>>
>> That is to say, those commits from the new repository that have a
>> common history for the two branches are duplicated.  The commits are
>> listed separately and have different SHA IDs, but they are clearly the
>> same commits (same comments, same svn version number).  Is there any
>> way to do what I want?  Really, all I want to do is change the parent
>> of "e" to be the HEAD of the old repository.
>
> If this is initial import, and not published anywhere, the simplest (I
> think) solution would be to use grafts file (.git/info/grafts) to
> change parent of 'k' from 'g' in ffa to 'g' in master, by adding the
> line with:
>
>  <sha1 of 'k'> <sha1 of 'g' on master>
>
> to .git/info/grafts.  Then examine history if everything is now all
> right (for example using gitk), and if everything is O.K. run
> git-filter-branch.
>
> See documentation for details.
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>

> 
> Thanks for the advice -- this did exactly what I wanted.
> 
> For anyone else wanting to do this: one thing that threw me for a
> while was that .git/info/grafts does not accept an abbreviated SHA,
> the full 40 hex digits is needed.  I would see "bad graft data" from
> gitk with no other explanation.  There is very little documentation
> that I could find on the grafts file; the best I could find was in the
> man page for git-filter branch:
>
>   http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html.