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

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

[paulfred]

I've been using git and git-svn to commit to a central SVN repository for
the last several months.  It's been working great so far, well enough that
I really, *really* don't want to go back.

But yesterday, someone committed a number of changes to svn:properties,
and there were no tree changes.  git-svn now fails to dcommit anything,
instead giving me the following output:

  $ git svn dcommit
  Committing to https://project.com/svn/trunk ...
  No changes
  68af7eb26504e324cd6e3a2d50cd0562852a2dca~1 == 68af7eb26504e324cd6e3a2d50cd0562852a2dca
  W: 68af7eb26504e324cd6e3a2d50cd0562852a2dca and refs/remotes/trunk differ, using rebase:
  :040000 040000 7d76021c10cebf4a0b5c8fdf614bec8e66734a28 197442c7bd8c29cdd11f52ffb18fbd882d1c7f50 M	eu
  Current branch master is up to date.
  # of revisions changed  
  before:
   683a4ed53d8859f184733eaeebc6fcb904aa1e3b
  10e85dc1c3b03b77dcabb53b26893b2d30bd56c5
  07c1f476b6a5feae410e315cae57d878e898896d
  27aad097ace7ec5db128032f29d775791463ddc7
    [...several commits omitted...]
  751e53e536c98bf9ee1bd8b876c56f06f6b6b059 
  
  after:
   68af7eb26504e324cd6e3a2d50cd0562852a2dca
  683a4ed53d8859f184733eaeebc6fcb904aa1e3b
  10e85dc1c3b03b77dcabb53b26893b2d30bd56c5
  07c1f476b6a5feae410e315cae57d878e898896d
  27aad097ace7ec5db128032f29d775791463ddc7
    [...all the same commits again omitted...]
  751e53e536c98bf9ee1bd8b876c56f06f6b6b059 
   If you are attempting to commit  merges, try running:
  	 git rebase --interactive --preserve-merges  refs/remotes/trunk 
  Before dcommitting


It's strange that it wanted to rebase, since I had already rebased on top of
remotes/trunk, and I have exactly one commit I'm trying to dcommit. After
rebasing, it appears to bail because 68af7e is in one list and not the other.
Well, 68af7e happens to be the commit with no tree changes, only svn property
changes.  And yet "git branch --contains 68af7e" output includes master.  (hmm,
but not remotes/trunk.  Shouldn't it? master^ == remotes/trunk)

Anyway, git svn rebase continues to pull in new changes from everyone else,
but won't dcommit mine.

Based on a suggestion from irc, I tried --no-rebase, and got:

  Attempting to commit more than one change while --no-rebase is enabled.
  If these changes depend on each other, re-running without --no-rebase may be required. at /usr/local/libexec/git-core/git-svn line 447.
  No changes
  68af7eb26504e324cd6e3a2d50cd0562852a2dca~1 == 68af7eb26504e324cd6e3a2d50cd0562852a2dca
  Unable to extract revision information  from commit 683a4ed53d8859f184733eaeebc6fcb904aa1e3b~1

But I don't know what to do with that error message.  Is it looking for the git-svn-id's?

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.

This is git version 1.6.0.4.761.g47577 on OS X 10.5.

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.

Thanks!

--Paul

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

[paulfred]

paulfred <paul.fredrickson@gmail.com> writes:
>
> 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.

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

 

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

[Sverre Rabbelier]

On Fri, Nov 21, 2008 at 02:30, paulfred <paul.fredrickson@gmail.com> wrote:
> $ 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?

Uhm, as I understand it, git svn needs that metadata to dcommit,
unless the .git/svn/git-svn/.rev_db is intact. The --no-metadata
switch should be used only when you're doing a one-time import of a
svn repo. During my usage of git svn, it removed the git-svn-id tags
from the commit message when you 'git svn dcommit', so I don't
understand why you need to use --no-metadata in the frist place.

-- 
Cheers,

Sverre Rabbelier