git svn - <file> was not found in commit <hash>
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?
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.
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.
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.
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.
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