On Tue, Mar 24, 2015 at 5:39 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Tue, Mar 24, 2015 at 8:55 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: >>> e.g. "db", "reports" or "scripts", we could keep going for a while. I >>> think I attempted to do this in the past and failed (don't remember >>> exactly why). Maybe I'll try again some time in future. >> >> I also was pretty sure that you had attempted this, but couldn't find >> a reference to it, so I didn't mention it in my response. However, >> with some more digging, I finally located it[1]. >> >> [1]: http://article.gmane.org/gmane.comp.version-control.git/259870 > > Thank you. I only looked at my repo and no branch name suggested it > (if only there is google search for a git repository..). So I gave up > because of performance reasons again but that was for enabling it > unconditionaly. If we enable it via a config variable and the user is > made aware of the performance implications, I guess it would be ok. So > it's back in my back log. How much does a config variable actually help? In a sense, one could argue that this is already an opt-in feature since it requires crafting gitignore in a particular fashion. Existing projects which have (properly) functioning gitignore rules won't trigger this behavior. In many cases, Git already allows people to shoot themselves in the foot if they desire, thus, as long as the potential performance impact is properly documented, this could be considered another such instance. -- 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