Re: git-svn seems confused about current HEAD

[tom fogal <tfogal@alumni.unh.edu>]

Hi all, just wanted to ACK and confirm that the recommended actions
were sound.

Eric Wong <normalperson@yhbt.net> writes:
> tom fogal <tfogal@alumni.unh.edu> 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