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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: May 18, 2011, 09:14 UTC
Message-ID: <4DD38DEE.4080604@drmicha.warpmail.net>
In-Reply-To: <20110518083314.GA22204@dcvr.yhbt.net>

Eric Wong venit, vidit, dixit 18.05.2011 10:33:

Show 41 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> 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.

git-svn's maintenance of these files would be simpler if we used a special file for that, say .git-svn-empty-dir, and teach dcommit to ignore it. That way git clones can share it and git svn dcommit is unimpaired. The only problem occurs when a new git-svn commits these, and old git clones that and an old git-svn dcommits from that clone.

>> 6. Documentation patches would also be required.
> 
> Agreed, along with automated test cases.
>

Michael