{"thread":{"id":"8820","subject":"pushing a project started in git back to a subversion repository...","startedAt":"2007-07-02T20:29:11Z","lastAt":"2007-07-03T15:06:42Z","messageCount":3,"participants":["Patrick Doyle","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46273","messageId":"e2a1d0aa0707021329p29242393ua10817c85ca7422a@mail.gmail.com","threadId":"8820","inReplyTo":null,"subject":"pushing a project started in git back to a subversion repository...","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2007-07-02T20:29:11Z","receivedAt":"2007-07-02T20:29:11Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"Well, I think I've parsed through the documentation and tips enough to\nfinally produce a script that does what I want it to do... and that\nwas: \"I started a project, tracking the revisions with git, and I want\nto track the changes and revisions on our company Subversion server.\"\n\nHere is what I did:\n1) packed up the existing git repository with \"git-pack-objects\"\n\n$ git-rev-list master | git-pack-objects --revs --stdout > ../mypack\n\n2) Used git-rev-list to find the name of first and last commits in my repo.\n\n*** 1st question: ****\nI can use\n\n$ git-rev-list -n 1 master\n\nto get the most recent commit.  Is there a similar shortcut to get the\nvery first commit?  (I used used \"tail -1\" to get the last line out of\ngit-rev-list\n\n3) Cloned the SVN repository, which I had previously created with an\nempty directory into which I wanted to import my new project\n\n$ git-svn clone url://path/to/repo/topdir\n\n4) unpacked the packfile into the new .git repo\n\n$ cd topdir\n$ git-unpack-objects < ../mypack\n\n5) Created a .git/info/grafts file with the first commit from my old\n.git repo grafted onto the single (empty directory) commit of this new\nrepo\n\n$ echo XXX YYY > .git/info/grafts\n\n6) Here's the scary part -- I overwrote .git/refs/heads/master with\nthe last commit from my old repo, so now \"master\" points to a chain of\ncommits going back to the beginning of time in the old repo and now\ngrafted onto the empty directory commit of my new repo.\n\n**** 2nd question: ****\nHow many of you cringed when I said I did this?  If so, why?\n\n7) Fetched the files into my empy directory\n\n$ git checkout\n\n8) And committed them back to the SVN repo:\n\n$ git-svn dcommit\n\n**** Last question: ****\nWhat happened to all of those objects I imported from the pack file?\nI can still see them in the .git/objects/*/* directories, but they\ndon't show up in git-ls-revs.  git-fsck doesn't report any errors.\ngit-gc seems like it packs them up -- I get 193 objects packed into\nthe pack file compared to 167 in a fresh clone of the (newly updated)\nsvn reposistory\n\nI'm also curious what experts would think of my fumbling efforts to\ntransfer this git-managed project into a git/svn-managed project,\nmaintaining the initial history.  Did I go tremendously out of my way\nto do something that was a one-line command?\n\n--wpd\n"},{"id":"46325","messageId":"20070703043733.GC4007@coredump.intra.peff.net","threadId":"8820","inReplyTo":"e2a1d0aa0707021329p29242393ua10817c85ca7422a@mail.gmail.com","subject":"Re: pushing a project started in git back to a subversion repository...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-03T04:37:33Z","receivedAt":"2007-07-03T04:37:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 02, 2007 at 04:29:11PM -0400, Patrick Doyle wrote:\n\n> Here is what I did:\n> 1) packed up the existing git repository with \"git-pack-objects\"\n> [...]\n> 2) Used git-rev-list to find the name of first and last commits in my repo.\n> [...]\n> 3) Cloned the SVN repository, which I had previously created with an\n> empty directory into which I wanted to import my new project\n> [...]\n> 4) unpacked the packfile into the new .git repo\n> [...]\n\nThat's a bit complex. How about:\n  1) clone the svn repository as in your step 3\n  2) fetch the old master into a local branch\n\n     git-fetch ../path/to/original master:original\n\n> 5) Created a .git/info/grafts file with the first commit from my old\n> .git repo grafted onto the single (empty directory) commit of this new\n> repo\n>\n> $ echo XXX YYY > .git/info/grafts\n\nSo you are grafting onto a totally uninteresting commit? That seems like\na hack to base your commits on something that is \"in\" git-svn. I suspect\nthere is a way to do it more elegantly, but I've never used git-svn, so\nI can't comment.\n\nYou could of course now do the graft as:\n\n  echo \"`git-rev-parse original` `git-rev-parse master`\" >.git/info/grafts\n\n> 6) Here's the scary part -- I overwrote .git/refs/heads/master with\n> [...]\n> 7) Fetched the files into my empy directory\n\nYou could also do this (while on the master branch):\n\n  git reset --hard original\n\nwhich will set master's sha1 to the same as your \"original\" branch, and\nupdate the working tree to have all of the files from that commit\n(because we used --hard).\n\nAt this point you can clean up the original branch:\n\n  git-branch -d original\n\n> **** 2nd question: ****\n> How many of you cringed when I said I did this?  If so, why?\n\nI cringed a little. It's actually not all that different than what\ngit-reset does, but git-reset will do nice things like locking and\nputting an entry in the reflog.\n\n> **** Last question: ****\n> What happened to all of those objects I imported from the pack file?\n\nThey were placed in the second repository's object database.\n\n> I can still see them in the .git/objects/*/* directories, but they\n> don't show up in git-ls-revs.  git-fsck doesn't report any errors.\n\nThere is no git-ls-revs. Not sure what you mean here. There are no\nerrors because all of the objects are referenced (by your new master\nbranch).\n\n> I'm also curious what experts would think of my fumbling efforts to\n> transfer this git-managed project into a git/svn-managed project,\n> maintaining the initial history.  Did I go tremendously out of my way\n> to do something that was a one-line command?\n\nMore or less. ;)\n\nPresumably you could take your _existing_ repository, point it at your\nsvn upstream (look in the .git/config of your svn-cloned repo, and there\nis presumably some svn config), and do the dcommit. Unfortunately, I\nhave the privilege of never having used svn or git-svn, so I can't\ncomment further.\n\n-Peff\n"},{"id":"46378","messageId":"e2a1d0aa0707030806w274fef7fkdcf9f2b0549c1c1c@mail.gmail.com","threadId":"8820","inReplyTo":"20070703142633.GC18597@coredump.intra.peff.net","subject":"Re: pushing a project started in git back to a subversion repository...","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2007-07-03T15:06:42Z","receivedAt":"2007-07-03T15:06:42Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"Oh dear, I just noticed that my previous reply was to you directly,\ninstead of the list at large.\n\nOn 7/3/07, Jeff King <peff@peff.net> wrote:\n> On Tue, Jul 03, 2007 at 09:56:06AM -0400, Patrick Doyle wrote:\n>\n> > I started off with something like this -- actually, I tried \"git-pull\"\n> > as well as \"git-fetch\", but in each case I ended up with a single\n> > commit in the SVN repository with a log message reading something like\n> > \"merged ../path/to/original\" instead of multiple commits, tracking the\n> > log messages from the original repository.\n>\n> git-pull is the equivalent of git-fetch followed by a merge. But you\n> don't want to do the merge, since you are going to graft. So you\n> definitely don't want to pull. However, the merge should have all of the\n> original commits in it, unless git-svn is somehow squashing the merge\n> down into a single commit.\n>\nI thought that the git-merge implicit in \"git-pull\" is what was\nsquashing the merge down into a single commit.  Nowadays, when I try a\n\"git-pull\" from my unrelated repository followed by a \"git-svn\ndcommit\", I get an error (from the dcommit command) that it is unable\nto extract revision information from one of the commits in the chain.\n\n>\n> > I found I needed to do \"git-branch -D original\", which makes me think\n> > that either I'm still not doing something completely Kosher here, that\n> > I'm still not understanding something, or that \"git-branch\" doesn't\n> > know about the \"info/grafts\" file.  (I put my money on the first\n> > explanation, and include the 3rd just for completeness).\n>\n> Hmm. It worked for me with '-d'. I did:\n>\nAhhh... if I do the \"git-branch -d original\" _before_ I do the\n\"git-svn dcommit\", then I get no warning, which makes sense because\neverything on the \"original\" branch is on the \"master\" branch.  But,\nif I do it _after_ I do the \"git-svn dcommit\", I get the warning and\nhave to use -D.  This is probably consistent with the history rewrite\nthat occurs with the \"dcommit\"\n\n>\n> > Oops, my bad, I mean \"git-rev-list\".  But even now, writing that, I\n> > realize that they wouldn't show up there either -- git-rev-list lists\n> > the commit chain for a given branch.  I'm just wondering what happened\n> > to commit 0e3e0e1e that was in my original git repo and which seems to\n> > have been replaced with commit 50a9979a in the new repo.  Of course\n> > the hash has changed, since git-svn added a \"git-svn-id\" line to my\n> > log message.  But I wonder why git-fsck doesn't report it as dangling.\n> > \"git-cat-file -p 0e3e\" prints it out.\n>\n> Hmm. I wonder if git-svn squashed your changes during the merge, as I\n> had mentioned previously. You could really get better answers from one\n> of the git-svn people. :)\nAhh, but I forgot to include any git-svn people in my previous reply :-(\n\n>\n>\n> It is presumably still referenced somewhere. Maybe even in your reflog\n> (try git-reflog show).\n>\nyep -- it's referenced there.  Not that this matters.  I'm in the\n\"gee, now I'm curious\" phase -- a dozen or so 200 byte entries\nsquished in the pack file aren't going to make any difference.\n\n> > > > I'm also curious what experts would think of my fumbling efforts to\n> > > > transfer this git-managed project into a git/svn-managed project,\n> > > > maintaining the initial history.  Did I go tremendously out of my way\n> > > > to do something that was a one-line command?\n> > >\n> > > More or less. ;)\n> > >\n> > > Presumably you could take your _existing_ repository, point it at your\n> > > svn upstream (look in the .git/config of your svn-cloned repo, and there\n> > > is presumably some svn config), and do the dcommit. Unfortunately, I\n> > > have the privilege of never having used svn or git-svn, so I can't\n> > > comment further.\n> > >\n> > I'm not sure that would work, as it appears that git-svn plays some\n> > games to associate git commits with SVN commits (hence my question\n> > about about why the 0e3e commit doesn't dangle anywhere).\n>\n> Right. It seems like there ought to be a way around this, but again, one\n> of the git-svn people can answer better. :) Maybe try re-asking your\n> question as \"is there a way to do this easily\" and cc'ing Eric Wong.\n>\nor, perhaps by bringing this back on the list, I'll get some more feedback :-)\n\n> > Thanks for the comments and explanations.  At this point, I'm not sure\n> > that git offers me anything better for me and my work-flows than what\n> > I get from Subversion, or CVS, (or RCS, or for that matter, SCCS -- if\n> > anybody still remembers that!), but I'm learning something new, and\n>\n> I thought the same way when I started with git, and then I realized that\n> git opened up a lot of possibilities for changing my workflow in little\n> ways. Coming from CVS, the concept of actually looking through history\n> for information on a code problem was foreign to me. But now I use\n> \"git-log -p -S\" all the time (-S is semi-confusingly documented under\n> git-diff). And that becomes more useful when I make concise,\n> well-documented commits, which is another thing git is great for. :)\n>\n> -Peff\n\nThanks again...\n\n--wpd\n"}]}