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

Sam Vilain [off-list ref] writes:

JM Ibanez wrote:

quoted

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/

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.