25

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?

Community
  • 1
  • 1
brad
  • 73,826
  • 21
  • 73
  • 85
  • This answer worked for me: http://stackoverflow.com/questions/2105064/i-need-to-un-fetch-some-revisions-from-git-svn - do a `git svn reset -r ` and then `git svn fetch` – the_mandrill Apr 20 '16 at 14:16

7 Answers7

34

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.

Ben Jackson
  • 90,079
  • 9
  • 98
  • 150
  • 2
    This happened to me when I ran `git svn dcommit` just as somebody else committed to SVN. git got very confused when doing the rebase and created a commit object with a tree that only contained the file which had been modified by my local commit, so it looked like entire contents of my working directory had disappeared. I was able to use `git svn reset` to refetch the bogus revision. – dOxxx May 03 '12 at 17:44
  • I ran into this because I had a file with an umlaut. Fortunately only a single file, so I use the svn-remote.svn.ignore-paths config entry like you suggested to ignore this single file and it worked. – CodeStage Apr 12 '16 at 08:06
  • @CodeStage: an alternative approach to solving the umlaut problem without simply ignoring that part of the tree, is [this answer](https://stackoverflow.com/a/34510538/1529709). – zb226 Jul 26 '17 at 10:31
  • "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." I had this happen to me, now I don't know how to do " fix the parent revision so that it includes the file being modified. " this part. – themagicalyang Feb 27 '20 at 11:22
  • @themagicalyang Look at the documentation for "git svn reset" – Ben Jackson Feb 29 '20 at 00:38
  • @BenJackson "Fix the ignore-paths or SVN permissions problem that caused "r2" to be incomplete in the first place." How do I fix permissions, I just got access to a specific folder and I am not svn admin. So the commit r10899 that modifies the file creates the issue. I do `git svn reset -r10899 -p` folllowed by the `git svn fetch` and it causes the same issue. – themagicalyang Mar 02 '20 at 12:08
  • @themagicalyang If you just got access to a folder, and you need it in your git-svn clone (therefore you can't ignore-paths it forever) you would have to git-svn-reset back to *when that folder was created in SVN*. Not back to the revision where you started seeing it. – Ben Jackson Mar 02 '20 at 17:14
  • @BenJackson assuming I'm unable to rewrite git history, is there any way to fix this? A new folder was made publicly available recently, but has history back several thousand revisions before exposed / the git-svn mirror was created. I tried manually committing the files as of nearest exposure revision, then running `git svn fetch` to continue syncing, but I got the same error. – HeroCC Dec 05 '20 at 21:41
  • I was able to find a workaround that doesn't require rewriting history or ignoring the issue. There may be a better way, but until it is known, I posted my solution below. – HeroCC Dec 05 '20 at 23:58
2

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.

Toughy
  • 767
  • 6
  • 5
2

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.

rerx
  • 1,133
  • 8
  • 19
lamusique
  • 392
  • 4
  • 6
2

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.

HeroCC
  • 988
  • 15
  • 33
  • FYI although I have not used `git-svn` in years my memory of that `git-svn-id` comment is that it's only used if the index in `.git/svn` is lost. So you might be able to speed up this workflow (if you need to) by updating the index instead of forcing it to rebuild from scratch. – Ben Jackson Dec 06 '20 at 03:20
1

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.

zb226
  • 9,586
  • 6
  • 49
  • 79
1

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
James John McGuire 'Jahmic'
  • 11,728
  • 11
  • 67
  • 78
1

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.

heisenbug
  • 484
  • 4
  • 9