Re: [PATCH/RFC] git-svn: New flag to add a file in empty directories

[Michael Haggerty <mhagger@alum.mit.edu>]

On 05/18/2011 10:33 AM, Eric Wong wrote:
> Michael Haggerty <mhagger@alum.mit.edu> 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@alum.mit.edu
http://softwareswirl.blogspot.com/