1

When I do git svn rebase on trunk-svn (which is my local copy of the SVN repo's trunk branch), I get the following error:

fatal: invalid upstream 'refs/remotes/origin/trunk'
rebase refs/remotes/origin/trunk: command returned error: 128

On a different branch, I get a different error:

Unable to determine upstream SVN information from working tree history

Checking out a new local copy of a different remote branch (which I had never checked out before) works fine, both the git checkout -b ... and the git svn rebase (with subsequent git svn rebase saying "up to date").

As far as I know, nothing changed about my local repository or the remote—this just started happening one day.

Here is what the SVN bit of .git/config looks like:

[svn-remote "svn"]
    url = svn://foo.bar.com/svn
    fetch = REPONAME/trunk:refs/remotes/origin/trunk
    branches = REPONAME/branches/*:refs/remotes/origin/*
    tags = REPONAME/tags/*:refs/remotes/origin/tags/*

This is the same as what I see when I do a fresh git svn clone -s of the repo. (I don't want to just use the fresh clone because I have a LOT of unmerged work in my old copy.)

And here are the relevant bits of .git/config for the branches in question:

[branch "trunk-svn"]
    remote = gitlab
    merge = refs/heads/trunk-svn
[branch "bugfix-svn"]
    remote = gitlab
    merge = refs/heads/bugfix-svn
[remote "gitlab"]
    url = git@gitlab.company.com:user.name/repo_name.git
    fetch = +refs/heads/*:refs/remotes/gitlab/*

Previous troubleshooting attempts have failed:

  1. git update-ref refs/remotes/git-svn refs/remotes/gitlab/trunk-svn: No apparent output of this command; same error happens with git svn rebase on trunk-svn.
  2. git fsck (suggested here) shows only dangling trees, commits, and blobs—i.e., nothing appears to be missing.
  3. Removing .git/svn/.caches (idea derived from a suggestion here) makes no difference.
  4. Adding rewriteRoot and rewriteUUID as suggested here makes no difference.

Any ideas would be much appreciated! Let me know if I can provide any more info that might be useful.

Sam R
  • 172
  • 11
  • `refs/remotes/` in Git is a namespace in which we find "subdirectories" (in quotes because these things aren't exactly *directories*, they just behave the same way) where the "directory name" is the remote. So `refs/remotes/git-svn` would never be appropriate; `refs/remotes/git-svn/something` would be the remote-tracking name for a remote named `git-svn`. I don't actually use `git-svn` myself so I can't say if it uses namespaces the way Git does, but that seems very likely. The `svn-remote` section you quote looks like it holds refspecs, or prototype refspecs. – torek Jun 08 '22 at 23:28
  • 1
    Meanwhile: `fatal: invalid upstream 'refs/remotes/origin/trunk'` just means that `refs/remotes/origin/trunk` does not point to a commit. How and why *that* came about is the first question to solve: is that the right name and should it exist and point to a commit, and if so, why doesn't it? Or, if it's the wrong name, how did something come to generate it here, what's the right name, etc? – torek Jun 08 '22 at 23:30
  • As a workaround: if you have a good fresh clone which is working OK — you may add the old clone as a "remote" (`git remote add oldclone file://.../oldrepo`), and simply pull the unmerged commits into the fresh clone, then drop the old one. I haven't used git-svn in years either; but as a general impression, diving into its source was the most reliable approach to figuring out what went astray. Even the manpage has omissions, there're `svn-remote.*` namespace remapping options which are handled in the perl code, but not documented in the manpage. HTH – ulidtko Jun 13 '22 at 09:30

0 Answers0