Unable to determine upstream SVN information from HEAD history

Question

Why do I get this error message?

score 40 · Answer 1 · edited Feb 29 '16 at 17:26

40

i got this message because of cloning the svn repo with --no-metadata option. Maybe that's the case with Your problem too.

When cloning it without that option everything is fine.

The --no-metadata option is meant to clone an SVN repository when the new git clone is to be come the canonical source in the future. It lacks the capacity to commit back to the SVN upstream, because it has no way to track differences between the git clone and the SVN upstream.

edited Feb 29 '16 at 17:26

jpaugh

6,634
4
38
90

answered Oct 26 '10 at 07:23

slafs

281
4
8

This is what I did. – Dan Gayle Jul 05 '16 at 17:08

score 35 · Accepted Answer · edited Jan 24 '23 at 23:49

(Posted Chad's "question" as an answer, fixed formatting and typos.)

There are a couple of causes for this error message.

The first, being the most common. You have two disjoint histories in your git repository: The history that you made in git, and the history from the remote svn repository.

To fix this, you need to make your git repository and svn repository share one common ancestor so git can figure what commits have changed what.

The following Article, discusses how to fix the problem:

The second possible cause of the problem is if you have an early version of git (possible, windows msysGit package) and you have just created a new git repository that communicates with a remote svn repository.

For example:

git svn init svn://svn.xxx.xxx/xxx/trunk
git svn fetch -r BASE:10

or

git clone svn://svn.xxx.xxx/xxx/trunk // Adds all the files in the revision...

And you get the follow error messages, when using the following commands.

$ git svn info
Unable to determine upstream SVN information from working tree

$ git svn rebase
Unable determine upstream SVN information working tree history

$ git svn dcommit
Unable to determine upstream SVN information from HEAD history

If you get the above error messages, first step is to check your git version. If your running a older git version <= 1.6.3.3.* that was in my case with (msysGit), then the easiest way to fix the problem is to update to a newest version of git such as 1.6.4.*.

The following Article discusses the problem in more detail.

Thanks for the link to the article, that let me do a switch do a different svn repository and now I'm back in business! — Matt Connolly, May 05 '11 at 00:20
For the first common case, the instructions on the Article is out of date. The poster here has updated instructions for the git beginners http://stackoverflow.com/questions/457694/how-to-commit-a-git-repo-to-an-empty-repo-svn-server/981765#981765 — James, Jul 12 '11 at 18:05
the http://eikke.com/importing-a-git-tree-into-a-subversion-repository/ helped me a lot — andrej, Jan 17 '14 at 10:15
I had this problem because the url to the subversion repository had changed. Make sure you can access the path configured in git using an svn client. — ahnkle, Apr 21 '15 at 08:36

score 18 · Answer 3 · edited May 15 '19 at 14:18

18

In my case, the HEAD from the svn repo should have been matched to the HEAD from the git repo. This should solve the problem:

git update-ref refs/remotes/git-svn refs/remotes/origin/master

If your use a different git branch for svn trunk, for example svntrunk, that branch should be referenced instead, that is:

git update-ref refs/remotes/git-svn refs/remotes/origin/svntrunk

edited May 15 '19 at 14:18

ceztko

14,736
5
58
73

answered Sep 26 '11 at 11:55

axel22

32,045
9
125
137

6

This did not fix my problem. – Michael Ozeryansky Jan 02 '15 at 04:44
1

This fixed my problem. – ZJ Lyu Sep 24 '16 at 03:30
5

Error: fatal: refs/remotes/origin/master: not a valid SHA1 – The Godfather Jul 22 '18 at 17:04
Worked for me! `refs/remotes/origin/master` was instead `refs/remotes/origin/svntrunk` since I keep svn trunk into another branch. I add this in the post since it's a community wiki. – ceztko May 15 '19 at 14:09
1

This reminded me that I only did `git clone` but **forgot `git svn init`** after that! This sequence worked: `git clone` → `git svn init` → `git update-ref`. – ulidtko Oct 10 '20 at 11:07

score 9 · Answer 4 · answered Jan 17 '14 at 10:55

got same problem, here is solution based on http://eikke.com/importing-a-git-tree-into-a-subversion-repository/ article:

$ git svn init http://server.com/svn/project/trunk/prototypes/proto1/
$ git svn fetch
  W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/svn/!svn/bc/100/dcom/trunk/prototypes/ws' path not found
  W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
  This may take a while on large repositories
  r147367 = 37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d (refs/remotes/git-svn)
$ svn log http://server.com/svn/project/trunk/prototypes/proto1/
  ------------------------------------------------------------------------
  r147367 | user | 2014-01-16 18:02:43 +0100 (Thu, 16 Jan 2014) | 1 line
  proto1 home
  ------------------------------------------------------------------------
$ git log --pretty=oneline master | tail -n1
  71ceab2f4776089ddbc882b8636aacec1ba5e832 Creating template
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #1

$ git show-ref git-svn
  37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d refs/remotes/git-svn
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #2

$ echo "71ceab2f4776089ddbc882b8636aacec1ba5e832 37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d" >> .git/info/grafts

$ git svn dcommit
  Committing to http://server.com/svn/project/trunk/prototypes/proto1 ...
    A   README.md
    A   pom.xml
A   src/main/java/.gitkeep
A   src/main/resources/.gitkeep
A   src/main/webapp/WEB-INF/web.xml
A   src/main/webapp/index.html
A   webapps/.gitkeep
  Committed r147419
    A   README.md
    A   pom.xml
A   src/main/java/.gitkeep
A   src/main/resources/.gitkeep
A   src/main/webapp/WEB-INF/web.xml
A   src/main/webapp/index.html
A   webapps/.gitkeep
  r147419 = 6a8bda7262739306d0a6e17eaad2802737dedc35 (refs/remotes/git-svn)
  No changes between current HEAD and refs/remotes/git-svn
  Resetting to the latest refs/remotes/git-svn
  Unstaged changes after reset:
    M   pom.xml
    M   src/main/webapp/index.html
    A   .gitignore
  Committed r147420
    M   pom.xml
    M   src/main/webapp/index.html
    A   .gitignore
  r147420 = 749b5acec55c341672bca08d07de8c336b5a4701 (refs/remotes/git-svn)
  No changes between current HEAD and refs/remotes/git-svn
  Resetting to the latest refs/remotes/git-svn
  ...etc...

Ed Ruder · Answer 5 · 2011-07-19T20:26:55.253

9

I got this message after I incorrectly added the -s/--stdlayout parameter to the git svn clone command for a Subversion repo that did not have the "standard Subversion layout" of trunk, tags, and branches relative paths.

(The Subversion repos I usually clone do have the standard relative paths, so when I cloned a Subversion repo that didn't have them using my usual git svn clone command, I got this cryptic message. The message is 100% correct, but almost 100% useless when trying to figure out what the problem is.)

edited Jul 19 '11 at 20:26

answered Jul 19 '11 at 20:01

Ed Ruder

578
6
13

I ran into this problem because i had added /trunk to the svn url while doing `git svn clone` with the `-s` option. So while not entirely the same as your situation, your comment helped me discover my mistake. thx! – jeroen Nov 30 '11 at 08:44

score 8 · Answer 6 · answered May 21 '13 at 10:52

8

You may also get this error, when you have checkout freshly created SVN repo.

I have solved this by

First doing an initial commit via svn command
Then clone the repo using git svn command.

answered May 21 '13 at 10:52

mohammadthalif

1
1
1

score 2 · Answer 7 · answered May 01 '13 at 22:33

2

I got this message because I used a FQDN for the git svn init command but the pre-existing git-svn integration was using just the hostname.

E.g. grep git-svn-id showed:

git-svn-id: svn://host/repo/...

But I did:

git svn init -Ttrunk svn://host.domain.com/repo

(We have a machine that regularly syncs a git repo with svn, then everyone else has git config --add remote.origin.fetch refs/remotes/*:refs/remotes/* to fetch down the svn synced branches.)

answered May 01 '13 at 22:33

Nathan Kidd

2,919
21
22

@jpaugh, run `git svn init` with a URL that exactly matches the `git-svn-id` value. – Nathan Kidd Mar 03 '16 at 14:31
So, you mean you can't fix it? You have to rebuild the repository? – jpaugh Mar 03 '16 at 14:35
Concretely, when I did `git svn init -Ttrunk svn://host.domain.com/repo` I got this error. So instead I did `git svn init -Ttrunk svn://host/repo` and everything worked fine. – Nathan Kidd Mar 03 '16 at 16:03
Ok. I had this problem with an existing project, which had worked fine for some time. I ended up recloning the SVN project, but I was hoping there was a better way. Thanks. – jpaugh Mar 03 '16 at 16:17

score 2 · Answer 8 · edited May 23 '17 at 12:34

2

Another cause for this problem is a wrong svn-remote.svn.rewriteRoot option (see this answer for instructions on using this).

The git-svn-id line in your commits imported from Subversion has to match the rewriteRoot URL if it is set.

edited May 23 '17 at 12:34

Community

1
1

answered Sep 25 '11 at 13:03

Daniel Hershcovich

3,751
2
30
35

1

The simple svn URL switcheroo from the linked answer here worked! – lkraav Aug 05 '15 at 15:28

score 1 · Answer 9 · edited Jun 20 '20 at 09:12

I saw this after I used BFG Repo-Cleaner https://rtyley.github.io/bfg-repo-cleaner/ and rewrited git history (intentional), and then tried to git svn fetch again. The message shows that the git <-> svn matching is lost.

To solves this, read https://git-scm.com/docs/git-svn
At the very bottom shows:

$GIT_DIR/svn/*/.rev_map.

Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the svn.noMetadata section above for details).

You need to have the git-svn-id comments in the commit comments to do this. If you do, you can delete the .rev_map.* file and rebuild it.

rm .git/svn/refs/remotes/git-svn/.rev_map.*
git svn info

This should show:

Rebuilding .git/svn/refs/remotes/git-svn/.rev_map.{snip} ...
...
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.{snip}
Path: .
...and then regular git svn info output

score 1 · Answer 10 · answered Oct 08 '19 at 11:45

It happened to me too. And I don't remember to have done something unusual. SVN repo existed, Git version was the most recent. There were 2 commits in local git repo that I wanted to commit to SVN. But when I ran:

git svn dcommit

I got the error.

git svn fetch

and

git svn rebase

didn't help. I got the same error after running them.

I think the problem could be caused by the fact that I did a squash of 2 local git commits previously. If it was the reason I still don't understand why a squash is a problem in this case (If you know, please, comment it).

Anyway I solved the problem by cloning the svn repo again to another working directory.

git svn clone .../trunk

Added the problematic git repo as a remote one:

git remote add last /cygdrive/c/data/problem_repo

and did a cherry-pick on all the commits that weren't yet moved to SVN. After that I could successfuly run:

git svn dcommit

score 0 · Answer 11 · edited Jun 08 '22 at 19:36

Another possible cause: If you have an svn-remote..rewriteUUID config set, git-svn may have trouble locating the right meta-data for the repository. For example, you might have something like this (see the git-svn man page for a discussion of why you would want to do this):

[svn-remote "svn"]
    url = svn://read-write.test.org
    fetch = trunk/project:refs/remotes/trunk
    rewriteRoot = http://read-only.test.org/svn
    rewriteUUID = 1234-abcd

... where 1234-abcd is the UUID of the read-only mirror. When you 'git svn fetch', you might end up with this file:

.git/svn/refs/remotes/trunk/.rev_map.5678-dcba

... where 5678-dcba is the UUID of the read-write repository. The fix is to:

$ mv .git/svn/refs/remotes/trunk/.rev_map.5678-dcba \
    .git/svn/refs/remotes/trunk/.rev_map.1234-abcd

Can't say for certain whether that is a durable solution, i.e., it might get confused next time you 'git svn fetch'. Might try a symlink rather than 'mv', I haven't experimented with that.

score 0 · Answer 12 · answered May 15 '23 at 15:01

0

Yet another possible cause: trying to rebase from the wrong branch. Remember to git checkout <your_branch> before running git svn rebase in case you haven't done that.

answered May 15 '23 at 15:01

Edu Castrillon

527
1
12
28

Unable to determine upstream SVN information from HEAD history

12 Answers12

Linked