Git development
 help / color / mirror / Atom feed
From: paulfred <paul.fredrickson@gmail.com>
To: git@vger.kernel.org
Subject: Re: git-svn confused by "empty" (svn prop change) commit
Date: Thu, 20 Nov 2008 17:30:17 -0800	[thread overview]
Message-ID: <m23ahlj26u.fsf@gmail.com> (raw)
In-Reply-To: m28wrfhz17.fsf@gmail.com

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

 

  reply	other threads:[~2008-11-21  1:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-20  3:11 git-svn confused by "empty" (svn prop change) commit paulfred
2008-11-21  1:30 ` paulfred [this message]
2008-11-21  6:32   ` Sverre Rabbelier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m23ahlj26u.fsf@gmail.com \
    --to=paul.fredrickson@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox