Hi all, just wanted to ACK and confirm that the recommended actions were sound. Eric Wong <normalperson@xxxxxxxx> writes: > tom fogal <tfogal@xxxxxxxxxxxxxx> wrote: > > I've got a repository that git-svn won't grab the most recent commits > > for: > > > > tf@shigeru tuvok ~/sw/bin/git svn find-rev HEAD > > 1164 > > tf@shigeru tuvok ~/sw/bin/git svn fetch > > tf@shigeru tuvok ~/sw/bin/git --version > > git version 1.6.3.3 > > > > The repository is actually at revision 1184. > > > > Interestingly, 1165 is also a commit which contains a string which > > is not representable in 8bit ASCII in the commit log. > > Wow, "svn log" seems to croak on 1165, too. How did you manage that? I > guess SVN servers don't check for UTF-8 validity at all in the > commits... *shrug*, I just copy-and-pasted a contributor's name into the log. I think in the future, I'll leave their names in the code instead of the log :) > I would get your SVN administrator to propedit the r1165 log entry > so people can see it in the future. Basically git svn relies on the > library version of "svn log", so if "svn log" fails, then git svn > usually has no chance of getting those revisions. I think Eric was referring to `svnadmin setlog' here. We've done that and everything seems to be working well. I'm slightly worried that I've rewritten history behind git's back -- I'm likening it to rebasing an upstream after pulling from it -- but everything seems okay so far without any gymnastics downstream. Perhaps it's not an issue because only a log message, and not actual code, has changed. *shrug*, for my case, re-cloning wouldn't be a disaster anyway. > > Is there a known workaround for this issue (or, how did I manage to > > `ignore' those commits in my initial repo)? > > Here's what I did when the initial clone got stuck at 1164: [snip] Thanks much for the help! -tom -- 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