Re: git-svn confused by "empty" (svn prop change) commit

From: paulfred <paul.fredrickson@gmail.com>
Date: Nov 21, 2008, 01:30 UTC
Message-ID: <m23ahlj26u.fsf@gmail.com>
In-Reply-To: <m28wrfhz17.fsf@gmail.com>

paulfred <paul.fredrickson@gmail.com> writes:

Show 6 quoted lines

>
> Other (perhaps important) details: I created the repository several months
> ago,and only recently put "[svn] noMetadata = true" in my config file because
> I'm the only person on the team using git, and nobody else wanted to see the
> git-svn-id messages.
>

Okay, I see that I missed in the documentation where it says setting noMetadata "must be done *before* any history is imported and these settings should never be changed once they are set. User error.

Show 5 quoted lines

>
> I suppose I could nuke everything and clone another shallow copy of the code
> from some point after the bad commit, but I'd be happy with any kind of
> work around that gets me dcommitting again.
>

So, that is what I tried to do today, only it doesn't appear to work either! Here's what I tried in more detail:

$ git svn init -T http://project.com/svn/trunk project --no-metadata

Then I edited my config to look like this:

[svn-remote "svn"]
            noMetadata = 1
            url = http://project.com/svn
            fetch = trunk/dev:refs/remotes/trunk

only changing the fetch line (I don't want to track web pages, etc. which are also under trunk). Followed by:

$ git svn fetch --revision 1156
$ git svn fetch
  (now it actually pulls everything since 1156 and checks out master)
  [hack, hack, hack]
$ git svn rebase
Unable to determine upstream SVN information from working tree history

at which point I realize I am probably screwed. But I try it anyway, since svn tells me no one else has checked anything in yet:

$ git svn dcommit Unable to determine upstream SVN information from HEAD history. Perhaps the repository is empty. at /usr/local/libexec/git-core/git-svn line 435.

So apparently my problem is NOT the empty commit at all, but trying to use noMetadata. I am surprised that it fails on a fresh download though. Is there something I might have done while hacking that would cause git-svn to lose track of trunk again? Is my only option to convince everyone to ignore the "noise" in my comments?

Thanks,

--Paul