Jeff King [off-list ref] 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.
Thanks.
On 28/10/16 15:54, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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.
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.
Finally, if this is a bad-idea, as I asked in the beginning, I will
consider the equine expired, cease flagellation and apologise for the noise.
On Fri, Oct 28, 2016 at 4:32 PM, Aaron Pelly [off-list ref] wrote:
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.
I wonder if smudge/clean filters can be used to recreate in-tree
.gitignore from .gitignore.d/*.
--
Duy
On Fri, Oct 28, 2016 at 10:32:07PM +1300, Aaron Pelly wrote:
On 28/10/16 15:54, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
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