On Wed, May 1, 2013 at 10:49 PM, Eric Wong <normalper...@yhbt.net> wrote:
> Junio C Hamano <gits...@pobox.com> wrote:
>> Eric Wong <normalper...@yhbt.net> writes:
>> That however is not a property of the directory containing it (or
>> the path to that .gitignore file) that is valid throughout the
>> history of the project.  It is a property of a specific tree object
>> (or you could say it is a property of the revision).  When at some
>> point in the history the upstream project adds .gitignore there
>> because many people use git-svn to contribute to their project, it
>> stops to be "should not be pushed back".
>> So it seems to me that the information this "placeholder added"
>> thing wants to express belongs to the tree object (and .gitignore
>> file itself is a natural place to have that information).
> Perhaps that was the better way to go...
> How would (the presumably few) existing users of this feature be
> affected?
> Currently with the config file, there are problems with interop between
> git-svn users that do git <-> git repo sharing, an updated version with
> the "placeholder added" .gitignore would allow git <-> git repo sharing,
> but only between users of newer git versions.  Perhaps that's fine and
> better than the current situation.

The original patch was geared towards increasing the fidelity of a
one-time svn->git migration (ie. where svn won't be used anymore).  I
recall investigating a method to enforce this by disallowing future
git-svn fetches, but I can't remember if I was successful.  Given this
perspective, I'm not sure that existing users need to be supported.

Then, as Junio mentions, future versions of git that store placeholder
info in the tree/file object could open the possibility of proper
git<->git sharing and resync with the original svn repo.

- Ray
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to