On 05/18/2011 10:33 AM, Eric Wong wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> 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 agree that the checkin should not be done automatically. But it is exactly to assist the explicit (manual) maintenance of placeholder files in Subversion that this feature could be useful. > 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. Indeed, by default git-svn should leave no trace. But there are other workplaces (mine included) where the use of git-svn is welcomed and supported. For us, features like "git svn create-ignore" are used to maintain .gitignore files that are committed to Subversion. Perhaps there needs to be a repository-wide flag to distinguish between: "conversion mode" -- This mode would be intended for full conversions to git. Placeholders created for empty directories, svn:ignore properties converted automatically into .gitignore files, etc. These actions would happen automatically whenever a Subversion commit is retrieved and the changes would be added to the git history as if they had happened in the corresponding SVN commit. "git svn dcommit" would be forbidden from such repositories. "working mode" -- This mode would support the use of git-svn as a front-end to Subversion. It would never push git-related changes to Subversion except at the explicit request of the user. In this mode, there would be commands (like "git svn create-ignore") to create git aids like placeholders and .gitignore files in the working copy, but only at the explicit request of the user, and these changes would never be committed automatically. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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