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@xxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
