Re: gitconfig includes

if > I thought that "--global" was useful in the first place outside of a > few narrow debugging cases. Ok. Perhaps I overestimated the utility of --global anyway, given the above... -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life!

Re: gitconfig includes

barf on my setup, but had it not been my script I'd be stuck. This is all a "FWIW" -- in case anyone thinks about use cases for a possible (future) change of the default. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life!

Re: gitconfig includes

On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano wrote: > Eli Barzilay writes: > >> So this is at least a documentation issue,... > > This already is documented, and I think it is clear enough. > >--[no-]includes > Respect include.* dire

gitconfig includes

made me even more surprised at the second, especially since the man blurb on --includes says "Defaults to on."... So this is at least a documentation issue, though I hope that #2 is a bug and that it *should* return "more"...? -- ((x=>x(x))(x=>x

Re: Minor bug: git config ignores empty sections

if `fn==store_aux`, but it shouldn't), calling it after the last variable in a section is seen so it's added after that. So, will something like this be acceptable? If so, is there anyone who I can ask questions about the code? -- ((x=>x(x))(x=>x(x)))

Minor bug: git config ignores empty sections

t x.y; } $ t;t;t $ grep -c '\[x\]' .git/config 3 $ git config x.z x $ t;t;t $ git config x.z x # adds another [x], but leaves it populated $ t;t;t;t;t;t;t;t $ grep -c '\[x\]' .git/config 4 -- ((x=>x(x))(x=>x(x))