Is there an advantage to using --no-metadata in git svn clone?

Question

I\'m doing a one-way convert from an SVN repository to a Git repository using git svn clone. Most examples do this with the --no-metadata flag - is th

Answer 1

One argument for using --no-metadata is that it doesn't change your commit messages. So even if you fetch from different locations, the commit messages will be the same and thus the commit hashes will be the same.

As an example, if I git svn init a repo from a local file: URL and later pull from an https: URL, every commit in the repo will be duplicated, since all of the commits with git-svn-id: file:///... will be fetched as git-svn-id: https:///... and encoded with new SHA1's.

If I specify --no-metadata then the commit message and this sha1 has will be the same and I can fetch from either the local filesystem or the subversion server because there will only be a single copy of any given svn commit in the git repo.

Personally I would prefer it if there were a minimal metadata option, which recorded the subversion revision id, but not the full metadata, but without messing around with git-filter-branch we are stuck with all or nothing.

Answer 2

It is actually not recommended:

This option is NOT recommended as it makes it difficult to track down old references to SVN revision numbers in existing documentation, bug reports and archives. If you plan to eventually migrate from SVN to git and are certain about dropping SVN history, consider git-filter-branch(1) instead. filter-branch also allows reformatting of metadata for ease-of-reading and rewriting authorship info for non-"svn.authorsFile" users.