git svn - <file> was not found in commit <hash>

Question

In the middle of pulling down a (rather large) svn repo with git-svn, I encountered the following error message (generic info substituted for real info):

Found possible branch point: svn://server/project/trunk/dir => svn://server/project/branches/branchname, <revision>
Initializing parent: refs/remotes/branchname@<revision>
project/trunk/dir/file was not found in commit <hash> (r<revision>)

I have read in other posts that it is possible to "un-fetch" this info through some tinkering. However, I would rather not lose the history and go forward as painlessly as possible.

How can I get git-svn fetch to continue?

Answer 1

OK, I was struggling with this for a while, but found a work-around. You will lose history of the files prior to the current git repo revision, but history will be kept intact, and you don't have to --ignore-paths. If rewriting history is an option, you should follow Ben Jackson's git svn reset answer.

Let's say you are on r123, and don't have access to the folder scripts/, which was created in r100. Somewhere down the line, you are granted access. This doesn't actually generate a revision, and is acceptable in SVN, but in git this effectively rewrites history. The git-svn repo continues being updated normally until something in scripts/ is modified (lets call it r126). Now git svn fetch fails because it doesn't know what to do -- it has a diff for a file that doesn't exist!

The way I fixed it was the following:

# Clone the directory that is missing one revision before it is next changed
$ svn co -r 125 https://your-server/svn/bla/scripts

# copy the contents and (-p)reserve their attributes
$ cp -pr scripts/* ~/your-git-svn-mirror-on-r125ish/scripts

# Get the git-svn-id of the the most recent commit
$ cd ~/your-git-svn-mirror-on-r125ish
$ git log -1 | grep git-svn-id
git-svn-id: https://your-server/svn/bla/trunk@125 7b6d...daf

That git-svn-id is the crux of the issue. It tells git-svn which commit maps to each revision. We're going to trick it into thinking our manual commit is actually an SVN commit.

# Add the missing new directory
$ git add scripts/

# An editor will open up, type a message warning this commit isn't a real svn revision
# The last line of your message should be the 'git-svn-id' from earlier.
$ git commit
<your message of warning>
git-svn-id: https://your-server/svn/bla/trunk@125 7b6d...daf

Now, there should be another commit that restores the files one commit before they are updated. Finally, we need to make git-svn rebuild the history, and take note of our new tricksy commit

# Backup the svn state in case something goes wrong
$ mv .git/svn .git/svn-BACKUP

# Cross your fingers, and fetch the changes from svn
# If your repo is large, it may take a long time to rebuild the mappings
$ git svn fetch

If all goes according to plan, you should have a repo with the new files, without rewriting history. You can git svn rebase and git push safely.

It may not be the most eloquent, but works as of git version 2.17.1.

Answer 2

For newer MacOSX systems configure

git config --global core.precomposeunicode false

, for older ones true. It is explained here:

https://michael-kuehnel.de/git/2014/11/21/git-mac-osx-and-german-umlaute.html

After setting the config option correctly I was able to import a SVN repository using svn2git (which uses git svn under the hood).

I also had

$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"

But I doubt that makes much of a difference.

Answer 3

I ran into this problem with directory names containing unicode characters, even though the error complains about a specific file in the directory. I tried

git svn fetch --ignore-paths path/up/to/filename

with the full path of the file, but that didn't work. Nor did trying the full path of directory with the unicode characters.

The command that finally worked was with the parent directory of the directory with unicode characters, like so:

git svn fetch --ignore-paths path/up/to/but-not-including-unicode-chars

Answer 4

A quick solution here is to reset to a revision fairly before problematic one.

git svn reset <a past revision>

For example, when an error message mentions r1000 e.g. run git svn reset r990, etc.

And run git svn rebase or git svn fetch.

Answer 5

Got the same error on Windows in relation to special characters (here: umlauts) in filenames:

(...)
r36770 = 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (refs/remotes/origin/xxx)
    M   doc/specification/xxx/2013 03 07 Workflows.xls
xxx/branches/xxx/doc/specification/xxx/2013 03 07 München.xls 
    was not found in commit 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (r36770)

The file in question was indeed in the referenced revision but git svn was unable to see it.

I was able to fix this problem by setting up environment variables for language and locale like this:

SET LANG=C
SET LC_ALL=C

You can execute these commands simply before running git svn, but they will only persist as long as the current shell lives. If you want to permanently set them up, head to Control Panel > System > Advanced system settings > Environment variables.

Answer 6

I got this error from git svn fetch when the repository had svn:externals urls set, and my --ignore-paths regexp would filter them out.

Answer 7

This probably means that you are receiving a new svn revision which modifies a file which (for some reason) does not exist in your git commit equivalent of the parent svn revision. One very easy way to cause this is to be inconsistent with --ignore-paths (originally there was no way to configure those and they had to be entered on every git-svn command line that might fetch). Another way is for someone on the svn server end to change repository permissions in such a way that a whole subtree of files suddenly appears (from your perspective) that your git repository has no history for.

The easiest way to get past this immediate problem and continue git-svn fetch is to use --ignore-paths (or better the svn-remote.svn.ignore-paths config entry) to ignore the problem part of the tree. You can get away with the command line argument to pass a single revision and you won't hit the problem again until someone modifies it on the svn side.

If you want to recover without --ignore-paths then you will need to fix the parent revision so that it includes the file being modified. I wrote git-svn reset specifically to do the "un-fetch" you refer to with less tinkering. It can reset your svn remote back to where the file was really created so you can integrate it into your history. This won't wipe out your working copies, but you will need to reparent any working branches on this new history.