Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > 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. Yeah, as I re-read that old thread, I really do not think anything wrong with the reasoning expressed in the proposed log message. It is pointless to hunt for "!do-not-exclude-me-please" in D/.gitignore when "D/" appears in .gitignore in the higher level, but if these two i.e. D/ !D/do-not-exclude-me-please appear together in .gitignore in the higher level, we can pay attention to that and pick up that single path. And doing so would be a lot more intuitive to the end user. My comment in the thread was only about the documentation being unclear and not about the feature, but somehow we failed to follow-up the topic to completion X-<. -- 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