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

> 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 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:
>

>
> > 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. :)

>
>
> It is presumably still referenced somewhere. Maybe even in your reflog
> (try git-reflog show).
>

> > > > 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.
>

> > 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