Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[JM Ibanez]

Hi,

I've been trying to convert an existing git-svn clone to noMetadata
(i.e. get rid of git-svn-id in the commit messages), primarily because
I've been using it to track two SVN repos which were originally just a
single repo-- they have the same UUID but are located on different
machines, and have branched significantly, so content-wise are no longer
the same repo.

Because the two repos have a single line of commits which they share, it
would be best if I could store that history in my git repo (as I need to
use it for merging between the two trees). Graphically, my current
history looks something like this:


    A -- B -- C -- D -- E -- a -- b -- c

    A'-- B'-- C'-- D'-- E'-- x -- y -- z

where, in reality, this should be represented as:

    A -- B -- C -- D -- E -- a -- b -- c
                         \
                          +- x -- y -- z

Because the ancestor revisions (A..E) have different commit messages
(because of the git-svn-id), they have differing SHA1 ids.  Which means
I have a hard time trying to track both branches using gitk.

I used git-filter-branch to strip off the git-svn-id lines, as follows:

 $ git filter-branch --msg-filter 'sed -e "s/^git-svn-id.*$//"' \
       --commit-filter 'NEW_SHA1=`git commit-tree "$@"`; \
         echo "s/$GIT_COMMIT/$NEW_SHA1/" >> $REMAP_FILE; \
         echo $NEW_SHA1' HEAD

The mappings between the old commit SHA1s and the new commit SHA1s I
store in $REMAP_FILE (somewhere), which I then execute as a sed script
against all my .rev_db files:

 $ find .git/svn/ -name '.rev_db' | xargs sed -f $REMAP_FILE -i.bak

Now, my problems is I've apparently confused git-svn. I can't seem to do
a git-svn rebase on this particular repo. For the record, I've changed
.git/config and set svn.noMetadata on this repo.

In particular, it seems that git-svn can't find the SVN metadata (even
if .rev_db exists). Exact error is "Unable to determine upstream SVN
information from working tree history".

The reason why I can't do a fresh git-svn clone of the two SVN repos is
the repo is already at ~7700 revisions, with large files. I don't have
the time to do a proper clone at the moment, and I tried this as an
alternative.

And yes, I did all of this on a copy of an existing repo, not the
original repo itself.

-- 
JM Ibanez
Software Architect
Orange & Bronze Software Labs, Ltd. Co.

jm@orangeandbronze.com
http://software.orangeandbronze.com/

Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[Sam Vilain]

JM Ibanez wrote:
> Hi,
> 
> I've been trying to convert an existing git-svn clone to noMetadata
> (i.e. get rid of git-svn-id in the commit messages), primarily because
> I've been using it to track two SVN repos which were originally just a
> single repo-- they have the same UUID but are located on different
> machines, and have branched significantly, so content-wise are no longer
> the same repo.
> 
> Because the two repos have a single line of commits which they share, it
> would be best if I could store that history in my git repo (as I need to
> use it for merging between the two trees). Graphically, my current
> history looks something like this:
> 
> 
>     A -- B -- C -- D -- E -- a -- b -- c
> 
>     A'-- B'-- C'-- D'-- E'-- x -- y -- z
> 
> where, in reality, this should be represented as:
> 
>     A -- B -- C -- D -- E -- a -- b -- c
>                          \
>                           +- x -- y -- z

Stop.

Use a graft.  in .git/info/grafts, put (expanding to the full SHA1s):

x E

Then just run something like 'git filter-branch E..z'

That will at least stitch them together.

To figure out what git-svn is expecting, make a new repository, use
git-svn init, and then git-svn fetch -rNNN (where NNN is a revision near
the most recent).  That will at least show you what git-svn expects the
metadata to look like, if you really want to go down the path you are
going down...

Sam.

Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[JM Ibanez]

Sam Vilain <sam@vilain.net> writes:

> JM Ibanez wrote:
>> Hi,
>> 
>> I've been trying to convert an existing git-svn clone to noMetadata
>> (i.e. get rid of git-svn-id in the commit messages), primarily because
>> I've been using it to track two SVN repos which were originally just a
>> single repo-- they have the same UUID but are located on different
>> machines, and have branched significantly, so content-wise are no longer
>> the same repo.
>> 
>> Because the two repos have a single line of commits which they share, it
>> would be best if I could store that history in my git repo (as I need to
>> use it for merging between the two trees). Graphically, my current
>> history looks something like this:
>> 
>> 
>>     A -- B -- C -- D -- E -- a -- b -- c
>> 
>>     A'-- B'-- C'-- D'-- E'-- x -- y -- z
>> 
>> where, in reality, this should be represented as:
>> 
>>     A -- B -- C -- D -- E -- a -- b -- c
>>                          \
>>                           +- x -- y -- z
>
> Stop.
>
> Use a graft.  in .git/info/grafts, put (expanding to the full SHA1s):

Actually, I forgot to mention that I already have grafts between the two
to track merges I performed previously. So, in fact, the history looks
like something this:

     A -- B -- C -- D -- E -- a -- b -- c -- d -- e -- f -- m3
                         \         \          \             /
                          \         \          \   /-------+
     A'-- B'-- C'-- D'-- E'-- x -- y -- m1-- z -- m2


where x, m1, m2, and m3 are squashed merge commits + grafts.

After git filter-branch with a graft of x to E, I get x having two
parents as what is needed *but* because the parent IDs are part of the
commit object, I now get x' y', etc, something like this:



     A -- B -- C -- D -- E -- a -- b -- c -- ...
                         |         |
                         |         |
                         |         +--- m1'- z'-- m2' -- ...
                         \         \
                          \         \
                           -- x -- y -- m1-- z -- ...


sort of. In any case, I get duplicate commits of m1, z, etc. after the
primary graft point. Is this expected?

-- 
JM Ibanez
Software Architect
Orange & Bronze Software Labs, Ltd. Co.

jm@orangeandbronze.com
http://software.orangeandbronze.com/

Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[Pascal Obry]

Sam Vilain a écrit :
> Use a graft.  in .git/info/grafts, put (expanding to the full SHA1s):

It is not the first time I see somebody talking about graft... I still 
don't know exactly what it is. Any pointers to literature about this?

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[Sam Vilain]

JM Ibanez wrote:
> Actually, I forgot to mention that I already have grafts between the two
> to track merges I performed previously. So, in fact, the history looks
> like something this:
> 
>      A -- B -- C -- D -- E -- a -- b -- c -- d -- e -- f -- m3
>                          \         \          \             /
>                           \         \          \   /-------+
>      A'-- B'-- C'-- D'-- E'-- x -- y -- m1-- z -- m2
> 
> 
> where x, m1, m2, and m3 are squashed merge commits + grafts.
> 
> After git filter-branch with a graft of x to E, I get x having two
> parents as what is needed *but* because the parent IDs are part of the
> commit object, I now get x' y', etc, something like this:
> 
> 
> 
>      A -- B -- C -- D -- E -- a -- b -- c -- ...
>                          |         |
>                          |         |
>                          |         +--- m1'- z'-- m2' -- ...
>                          \         \
>                           \         \
>                            -- x -- y -- m1-- z -- ...
> 
> 
> sort of. In any case, I get duplicate commits of m1, z, etc. after the
> primary graft point. Is this expected?

I think you need to use a parent filter that looks up the old commit ID
in the grafts, and adjusts the parents accordingly.  I don't think I'd
be able to nail it down any further than that without actually trying.

I think the intent of git filter-branch's grafting support is that this
shouldn't happen, so if you can produce a test case then the bug can
likely be fixed.

Sam.

Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[Sam Vilain]

Pascal Obry wrote:
> Sam Vilain a écrit :
>> Use a graft.  in .git/info/grafts, put (expanding to the full SHA1s):
> 
> It is not the first time I see somebody talking about graft... I still 
> don't know exactly what it is. Any pointers to literature about this?

Documentation/repository-layout.txt in the distribution

Debian for one installs this to
/usr/share/doc/git-doc/repository-layout.html

Sam.

Re: Stripping 'git-svn-id' from commit messages, and switching to svn.noMetadata

[Pascal Obry]

Sam,

> Debian for one installs this to
> /usr/share/doc/git-doc/repository-layout.html

Thanks, will have a look.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595