It's not really *required* to do this mapping, it's only very convenient so that github can create links from every commit to the committer account, and also for future statistics.
Another thing to decide is what to do about tags. Git-svn models tags as separate commits (because each svn tag creates a new revision), but that's not how git usually handles tags. You could go over each tag and redefine it, e.g. instead of the 3.1.0GA tag being here : https://github.com/mausch/NHibernate/commit/a971c20f9be652a59bc467d8e61bbad2f2928ef3as a separate commit, it would be here: https://github.com/mausch/NHibernate/commit/3c2d5fdbeeebc87f089bac2306792b8ef4459a81which is the commit before that. Clone the repository and use gitk to better visualize this. Also, tags in git can be lightweight, annotated or even cryptographically signed if you're really paranoid about people redistributing code with edited tags. -- Mauricio On Tue, Aug 2, 2011 at 4:27 PM, Mauricio Scheffer < [email protected]> wrote: > Right now, on my github mirror all committers have names autogenerated by > git-svn. For example: "patearl > <patearl@d2eaab8a-a80d-0410-be94-99ecdb4ea5df>". > > Git filter-branch should be used to change all commits and map those > autogenerated names to the actual github accounts (e.g. the email used for > https://github.com/patearl ), otherwise all commits are pretty much > anonymous, detached from their actual owners. > Here's a sample script that does this for a single user: > http://progit.org/book/ch6-4.html#changing_email_addresses_globally > The filter-branch docs also has some examples about this: > http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html > > Cheers, > Mauricio > > > > On Tue, Aug 2, 2011 at 4:00 PM, Patrick Earl <[email protected]> wrote: > >> On Tue, Aug 2, 2011 at 10:35 AM, Mauricio Scheffer >> <[email protected]> wrote: >> > If NHibernate decides to move to git, you might be interested in my >> > github mirror: https://github.com/mausch/NHibernate , which contains >> > of course the whole history, is up to date, and has all tags and >> > branches. >> >> That sounds great Mauricio. Thanks for the heads up. >> >> > All that would be needed to complete the migration is mapping the >> > committers to their proper github accounts (which isn't hard, just >> > some filter-branches, doesn't take too long). So the slowest part >> > (migrating the actual commits from SVN to git) is already done. >> >> Can you suggest what you mean here to do the mapping? It sounds like >> you have a very clear idea of what needs to be done. >> >> > Of course, tooling support is a separate issue. I don't know what >> > tools NHibernate currently uses that depend on SVN (could be nant for >> > tagging, TeamCity, JIRA integration, ...) >> >> TeamCity has built-in GIT support, so that shouldn't be a problem. >> The releases haven't even been using the SVN revision for the version >> number, so we're more or less okay on that front. We don't have JIRA >> set up with any VCS integration right now, so integrating would only >> be an improvement. Do we have some sort of script or anything to run >> tagging on release? The release process is a mystery to me >> personally. :) >> >> Patrick Earl >> > >
