On Fri, Oct 28, 2016 at 10:32:07PM +1300, Aaron Pelly wrote: > On 28/10/16 15:54, Junio C Hamano wrote: > > Jeff King <p...@peff.net> writes: > > > >> However, as I said elsewhere, I'm not convinced this feature is all that > >> helpful for in-repository .gitignore files, and I think it does > >> introduce compatibility complications. People with older git will not > >> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local > >> matter. > > > > As I do not see the point of making in-tree .gitignore to a forest > > of .gitignore.d/ at all, compatibility complications is not worth > > even thinking about, I would have to say. > > Well; that saves some work. :) > > I do not suggesting making this mandatory. I think it adds value and it > is a common and understood mechanism. But, if it is abhorrent, consider: > > There is precedent for including files in git-config. This could be > extended to ignore files. The code is not similar, but the concept is. I > could live with it.
Yes, but note that we don't have in-tree config files, either (to large degree because of the security implications). Perhaps Junio can clarify himself, but I took his statement to mean only that in-tree .gitignore.d is not worth worrying about, but that $GIT_DIR/info/exclude.d or similar would be OK (but perhaps I interpreted that way because that's my own position :) ). > Or how about a new githook that can intelligently create or return the > details? This would be my least favourite option unless it was > configured in an obvious place. That seems more complicated than is really merited, and probably doesn't perform great either (it's an extra forked process for almost every git operation). And obviously would not work for an in-tree solution anyway, as we do not want to run arbitrary code. -Peff
