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
