Rewriting references to existing commits in commit messages with filter-branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 Hello,

 I'm in the process of converting an existing svn repository to git. The
first step was a standard "git svn clone" that went successfully (after
taking 15 hours to complete). However I don't want to stop there and would
like massage the repository a little before making it publicly available.

 The first thing I'd like to do is to replace all references to subversion
revision numbers in the commit messages with the corresponding git commit
SHA1s. I've written a small message filter script called "svnmsg2git" that
searches for all occurrences of r12345, runs "git svn find-rev r12345" and
then -- and this is the important part -- looks up the new commit id
corresponding to this under .git-rewrite/map. This seemed to work well in
limited testing I did initially but after running

git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all

on all ~50k revisions, I have a couple of dozens of errors which happen
because the file .git-rewrite/map/$commit doesn't exist yet when I'm trying
to look it up.

 Does anybody know of a way to fix this? This happens apparently because
filter-branch doesn't process the commits in their svn order, and when one
of them is on a branch while the other one is on the trunk, it can happen
that the commit references a previous svn revision is processed before the
commit corresponding to this revision itself. At least this is the only
explanation I see. But even if my hypothesis is correct, I still have no
idea about how to force filter-branch to do things in the "right" order.

 Thanks in advance for any ideas!
VZ

Attachment: pgpIgt43Ir3qj.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]