All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Douma <n.douma@nekoconeko.nl>
To: git@vger.kernel.org
Subject: Migrating SVN to Git, and preserve merge information
Date: Tue, 10 Apr 2012 17:18:11 +0200	[thread overview]
Message-ID: <4F844F33.5000004@nekoconeko.nl> (raw)

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Hi,

I currently have two SVN repositories I'm looking to convert to Git.
While the process itself isn't all that hard (following this guide[1]),
I'm looking to do a bit more than just convert raw commits.

The repositories basically have two main branches at a time, for example:

* trunk
* current version, for example 3.5

Our SVN workflow consisted of working on trunk, and then manually
merging single commits from trunk to the other branch. We quite
consistently mentioned the merged commits in the SVN commit message, and
I'm looking to use this information to generate a more accurate tree in
Git. The commit messages are for example:

trunk  rev 100: Fixed important bug
branch rev 101: Merged r100 from trunk

Or more elaborate:

branch rev 200: Merged r100,r101,r.... from trunk

In these examples, tools like gitk or git log should show a line from
rev 100 to rev 101 in the first example, and lines from r100, r101,rn to
rev 200 in example two.

I have tried to create a custom grafts file to create the parent-child
relations above, and basically finds all merge commits and converts them
into graft lines like so:

<merge commit sha hash> <original git parent sha hash> <sha hash of
merged rev 1> ... <sha hash of merged rev n>

This all works to a certain extent, but the problem arises when trying
to view older history in these repositories. If I use the grafts file,
and do `gitk --all`, gitk freezes. Gitg doesn't show commits before a
certain point. tig and `git log --graph` all show a huge amount of
parentless commits near the bottom. All of this leads me to the
conclusion that something is wrong with the method of using grafts,
rather than problems in the individual tools.


Can someone find something obvious that I'm missing in the above
approach? Or alternatively suggest another more appropriate method of
achieving the same results in Git?

Kind regards,

Nick Douma



[1]: http://john.albin.net/git/convert-subversion-to-git


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

             reply	other threads:[~2012-04-10 15:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-10 15:18 Nick Douma [this message]
2012-04-10 22:57 ` Migrating SVN to Git, and preserve merge information Andrew Sayers
2012-04-11  7:24   ` Nick Douma
2012-04-11 11:13     ` Santi Béjar
2012-04-11 17:58     ` Andrew Sayers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F844F33.5000004@nekoconeko.nl \
    --to=n.douma@nekoconeko.nl \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.