Unable to determine upstream SVN information from HEAD history

Why do I get this error message?

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.

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

git svn rebase

unable determine upstream svn information working tree history or

  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.

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

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

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

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

I have solved this by

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

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.

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

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

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

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