pushing a project started in git back to a subversion repository...

pushing a project started in git back to a subversion repository...

[Patrick Doyle]

Well, I think I've parsed through the documentation and tips enough to
finally produce a script that does what I want it to do... and that
was: "I started a project, tracking the revisions with git, and I want
to track the changes and revisions on our company Subversion server."

Here is what I did:
1) packed up the existing git repository with "git-pack-objects"

$ git-rev-list master | git-pack-objects --revs --stdout > ../mypack

2) Used git-rev-list to find the name of first and last commits in my repo.

*** 1st question: ****
I can use

$ git-rev-list -n 1 master

to get the most recent commit.  Is there a similar shortcut to get the
very first commit?  (I used used "tail -1" to get the last line out of
git-rev-list

3) Cloned the SVN repository, which I had previously created with an
empty directory into which I wanted to import my new project

$ git-svn clone url://path/to/repo/topdir

4) unpacked the packfile into the new .git repo

$ cd topdir
$ git-unpack-objects < ../mypack

5) Created a .git/info/grafts file with the first commit from my old
.git repo grafted onto the single (empty directory) commit of this new
repo

$ echo XXX YYY > .git/info/grafts

6) Here's the scary part -- I overwrote .git/refs/heads/master with
the last commit from my old repo, so now "master" points to a chain of
commits going back to the beginning of time in the old repo and now
grafted onto the empty directory commit of my new repo.

**** 2nd question: ****
How many of you cringed when I said I did this?  If so, why?

7) Fetched the files into my empy directory

$ git checkout

8) And committed them back to the SVN repo:

$ git-svn dcommit

**** Last question: ****
What happened to all of those objects I imported from the pack file?
I can still see them in the .git/objects/*/* directories, but they
don't show up in git-ls-revs.  git-fsck doesn't report any errors.
git-gc seems like it packs them up -- I get 193 objects packed into
the pack file compared to 167 in a fresh clone of the (newly updated)
svn reposistory

I'm also curious what experts would think of my fumbling efforts to
transfer this git-managed project into a git/svn-managed project,
maintaining the initial history.  Did I go tremendously out of my way
to do something that was a one-line command?

--wpd

Re: pushing a project started in git back to a subversion repository...

[Jeff King]

On Mon, Jul 02, 2007 at 04:29:11PM -0400, Patrick Doyle wrote:

> Here is what I did:
> 1) packed up the existing git repository with "git-pack-objects"
> [...]
> 2) Used git-rev-list to find the name of first and last commits in my repo.
> [...]
> 3) Cloned the SVN repository, which I had previously created with an
> empty directory into which I wanted to import my new project
> [...]
> 4) unpacked the packfile into the new .git repo
> [...]

That's a bit complex. How about:
  1) clone the svn repository as in your step 3
  2) fetch the old master into a local branch

     git-fetch ../path/to/original master:original

> 5) Created a .git/info/grafts file with the first commit from my old
> .git repo grafted onto the single (empty directory) commit of this new
> repo
>
> $ echo XXX YYY > .git/info/grafts

So you are grafting onto a totally uninteresting commit? That seems like
a hack to base your commits on something that is "in" git-svn. I suspect
there is a way to do it more elegantly, but I've never used git-svn, so
I can't comment.

You could of course now do the graft as:

  echo "`git-rev-parse original` `git-rev-parse master`" >.git/info/grafts

> 6) Here's the scary part -- I overwrote .git/refs/heads/master with
> [...]
> 7) Fetched the files into my empy directory

You could also do this (while on the master branch):

  git reset --hard original

which will set master's sha1 to the same as your "original" branch, and
update the working tree to have all of the files from that commit
(because we used --hard).

At this point you can clean up the original branch:

  git-branch -d original

> **** 2nd question: ****
> How many of you cringed when I said I did this?  If so, why?

I cringed a little. It's actually not all that different than what
git-reset does, but git-reset will do nice things like locking and
putting an entry in the reflog.

> **** Last question: ****
> What happened to all of those objects I imported from the pack file?

They were placed in the second repository's object database.

> I can still see them in the .git/objects/*/* directories, but they
> don't show up in git-ls-revs.  git-fsck doesn't report any errors.

There is no git-ls-revs. Not sure what you mean here. There are no
errors because all of the objects are referenced (by your new master
branch).

> I'm also curious what experts would think of my fumbling efforts to
> transfer this git-managed project into a git/svn-managed project,
> maintaining the initial history.  Did I go tremendously out of my way
> to do something that was a one-line command?

More or less. ;)

Presumably you could take your _existing_ repository, point it at your
svn upstream (look in the .git/config of your svn-cloned repo, and there
is presumably some svn config), and do the dcommit. Unfortunately, I
have the privilege of never having used svn or git-svn, so I can't
comment further.

-Peff

Re: pushing a project started in git back to a subversion repository...

[Patrick Doyle]

Oh dear, I just noticed that my previous reply was to you directly,
instead of the list at large.

On 7/3/07, Jeff King <peff@peff.net> wrote:
> On Tue, Jul 03, 2007 at 09:56:06AM -0400, Patrick Doyle wrote:
>
> > I started off with something like this -- actually, I tried "git-pull"
> > as well as "git-fetch", but in each case I ended up with a single
> > commit in the SVN repository with a log message reading something like
> > "merged ../path/to/original" instead of multiple commits, tracking the
> > log messages from the original repository.
>
> git-pull is the equivalent of git-fetch followed by a merge. But you
> don't want to do the merge, since you are going to graft. So you
> definitely don't want to pull. However, the merge should have all of the
> original commits in it, unless git-svn is somehow squashing the merge
> down into a single commit.
>
I thought that the git-merge implicit in "git-pull" is what was
squashing the merge down into a single commit.  Nowadays, when I try a
"git-pull" from my unrelated repository followed by a "git-svn
dcommit", I get an error (from the dcommit command) that it is unable
to extract revision information from one of the commits in the chain.

>
> > I found I needed to do "git-branch -D original", which makes me think
> > that either I'm still not doing something completely Kosher here, that
> > I'm still not understanding something, or that "git-branch" doesn't
> > know about the "info/grafts" file.  (I put my money on the first
> > explanation, and include the 3rd just for completeness).
>
> Hmm. It worked for me with '-d'. I did:
>
Ahhh... if I do the "git-branch -d original" _before_ I do the
"git-svn dcommit", then I get no warning, which makes sense because
everything on the "original" branch is on the "master" branch.  But,
if I do it _after_ I do the "git-svn dcommit", I get the warning and
have to use -D.  This is probably consistent with the history rewrite
that occurs with the "dcommit"

>
> > Oops, my bad, I mean "git-rev-list".  But even now, writing that, I
> > realize that they wouldn't show up there either -- git-rev-list lists
> > the commit chain for a given branch.  I'm just wondering what happened
> > to commit 0e3e0e1e that was in my original git repo and which seems to
> > have been replaced with commit 50a9979a in the new repo.  Of course
> > the hash has changed, since git-svn added a "git-svn-id" line to my
> > log message.  But I wonder why git-fsck doesn't report it as dangling.
> > "git-cat-file -p 0e3e" prints it out.
>
> Hmm. I wonder if git-svn squashed your changes during the merge, as I
> had mentioned previously. You could really get better answers from one
> of the git-svn people. :)
Ahh, but I forgot to include any git-svn people in my previous reply :-(

>
>
> It is presumably still referenced somewhere. Maybe even in your reflog
> (try git-reflog show).
>
yep -- it's referenced there.  Not that this matters.  I'm in the
"gee, now I'm curious" phase -- a dozen or so 200 byte entries
squished in the pack file aren't going to make any difference.

> > > > I'm also curious what experts would think of my fumbling efforts to
> > > > transfer this git-managed project into a git/svn-managed project,
> > > > maintaining the initial history.  Did I go tremendously out of my way
> > > > to do something that was a one-line command?
> > >
> > > More or less. ;)
> > >
> > > Presumably you could take your _existing_ repository, point it at your
> > > svn upstream (look in the .git/config of your svn-cloned repo, and there
> > > is presumably some svn config), and do the dcommit. Unfortunately, I
> > > have the privilege of never having used svn or git-svn, so I can't
> > > comment further.
> > >
> > I'm not sure that would work, as it appears that git-svn plays some
> > games to associate git commits with SVN commits (hence my question
> > about about why the 0e3e commit doesn't dangle anywhere).
>
> Right. It seems like there ought to be a way around this, but again, one
> of the git-svn people can answer better. :) Maybe try re-asking your
> question as "is there a way to do this easily" and cc'ing Eric Wong.
>
or, perhaps by bringing this back on the list, I'll get some more feedback :-)

> > Thanks for the comments and explanations.  At this point, I'm not sure
> > that git offers me anything better for me and my work-flows than what
> > I get from Subversion, or CVS, (or RCS, or for that matter, SCCS -- if
> > anybody still remembers that!), but I'm learning something new, and
>
> I thought the same way when I started with git, and then I realized that
> git opened up a lot of possibilities for changing my workflow in little
> ways. Coming from CVS, the concept of actually looking through history
> for information on a code problem was foreign to me. But now I use
> "git-log -p -S" all the time (-S is semi-confusingly documented under
> git-diff). And that becomes more useful when I make concise,
> well-documented commits, which is another thing git is great for. :)
>
> -Peff

Thanks again...

--wpd