Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: <snip> 1..3 are all very good points > 4. If it is a goal to support long-term tracking of a Subversion > repository, then it would be good to add a config option to turn on this > feature permanently for a git-svn repository, so that the user doesn't > have to enter the extra options with each command invocation. Command-line options should be automatically converted into config file options inside git svn. We should however discourage this from getting mixed... > 5. It might be useful to allow the placeholder files to be committed to > Subversion, so that other git-svn users based off the same Subversion > repository don't have to worry about empty directories. This would > typically be something that people would want to do semi-manually in > specific Subversion commits. To support this user case, one could add a > similar option to "git svn mkdirs" that causes the placeholder files to > be created in the working copy but not committed. Then the user could > review the suggested changes, perhaps add lines to the .gitignore files, > commit to git, then dcommit to Subversion. No, too hard and error-prone, I think. This would require tracking which .gitignore files are git-only and which are not (some SVN repos have .gitignore files explicitly checked in, but that should /always/ be done explicitly by the user every time). I would go as far as to have a flag to disable dcommit (and set-tree) on any repo that uses this placeholder feature. SVN-only folks could be very unhappy to see placeholder files, especially in some cases where placeholders may break builds or cause information leaks. I strongly believe git-svn should leave no trace. Nobody but the user using git-svn should know they're using git-svn to interact with an SVN repo. This allows users to stay under the radar of any idiotic rules (or knee-jerk reactions of FUD) their organization may have against using non-standard SVN clients. So far, it's worked out pretty well, git-svn users slowly and quietly develop clout and influence to migrate their repos from SVN to git. > 6. Documentation patches would also be required. Agreed, along with automated test cases. -- Eric Wong -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html