问题
While trying to clone an existing Subversion repository using git-svn using standard layout, I got a bunch of W: -empty_dir (and W: +empty_dir) warnings. The cloned git repository seems to be working, i.e. I can do usual git operations and dcommit to SVN repository.
The real problem is that the initial clone and rebase create some empty directories that do not exist in SVN repository, at the top of the repository (along with other directories in trunk). These directories contain no file but just some empty directories inside them. It seems that the "W: -empty_dir" warnings correspond to these empty directories.
I looked for empty directories by checking out the whole repository using SVN, but there is no empty directory. I also checked through SVN if the repository has files with special properties, but there was not any other than "executable" and "mime-type".
The existing repository was not originally following the standard layout, but I cleaned it up so that the top directories are just "trunk", "tags", and "branches".
What can be causing the creation of these empty directories that do not exist under Subversion?
回答1:
Without knowing exactly where those empty directories came from, you could tell git-svn to remove them by using the --rmdir command line option or svn.rmdir configuration option.
See git-svn OPTIONS man page and
Remove directories from the SVN tree if there are no files left behind.
SVN can version empty directories, and they are not removed by default if there are no files left in them. git cannot version empty directories.
Enabling this flag will make the commit to SVN act like git.
The warning comes from SVN tags (which are "directories") not supported by git-svn, as in "git svn interrupted, then I lost all the tags, how to fix it?".
From this thread:
SVN tracks directories, git doesn't, so empty directories cannot be represented in git.
Those warnings on files seem to tell you which files that got deleted, causing an empty directory to be left in place, in that particularsvn commitbeing imported.
The difference between -empty_dir and +empty_dir is about how the empty directory appears in the SVN repo:
-empty_dir
A bunch of files are deleted, leaving a directory (branch or tag) empty.
+empty_dir
An empty branch or tag has just been created in the SVN revision being imported, and git-svn won't import an empty directory.
Note that you can restart the import after that warning.
回答2:
One of the things with git is that it does not track directories. It is all about content (files) in git. So empty directories are pretty much left to languish in your local repo. The best way to get rid of empty directories in your local repo is to do git clean -d.
Checkout man git clean for more info.
回答3:
Regarding the question in the title (which is what draws google's attention to this page), according to my findings, using either git-svn 1.7.1 or git 1.8.5: the warning W: -empty_dir: x/y/z means that the file or folder x/y/z was removed in the SVN changeset. Unless you specified -q (--quiet), that fact was already reported as D x/y/z. What I think it tries to say is that as a consequence, the folder x/y might have become empty and was therefore removed from the git view. It is far more common that x/y did not become empty and there is nothing peculiar going on.
In practice, if removing x/y/z would have left x/y empty, you would probably have removed the whole of x/y in the SVN changeset, and the removal of x/y/z would not even be reported separately. So you would not get that warning, but instead W: -empty_dir: x/y warns you that x might have become empty, which you know it didn't because then you would have deleted x...
If, on the other hand, you did leave empty directories around and want to keep them, I guess you would use --preserve-empty-dirs and I see no point in the warning either (if it still appears in that case).
So in short, ignore it. Unlike W: +empty_dir, which is a different story.
来源：https://stackoverflow.com/questions/4147356/git-svn-w-empty-dir-warnings-what-do-they-mean