On Fri, Jul 04, 2025 at 09:53:13AM -0400, Todd Zullinger wrote: > > Thanks for digging this up. So in a sense this is an obscurely- > > documented behavior that people could reasonably choose to rely > > upon. I think only more reason to document this more prominently. > > The commit which added it, d65d2b2fb4 (init: handle empty > "template" parameter, 2008-07-28), notes the behavior: > > init: handle empty "template" parameter > > If a user passes "--template=", then our template parameter > is blank. Unfortunately, copy_templates() assumes it has at > least one character, and does all sorts of bad things like > reading from template[-1] and then proceeding to link all of > '/' into the .git directory. > > This patch just checks for that condition in copy_templates > and aborts. As a side effect, this means that --template= > now has the meaning "don't copy any templates." > > It was released in 1.5.6.5, just in case anyone is looking > at the release notes for 1.5.6.4 and wondering why this > isn't mentioned. :) > > It came up in <20080722200911.GA3097@xxxxxxxxxxxxxxxxxxxxx> > on the list. > > It's been this way for 17 years and seems unlikely to > change. Documenting it ought to be a good thing. Oops, I suppose this is my fault. I agree that this is the intended behavior, and probably ought to be documented. However, as Kristoffer mentioned, "--no-template" should work in the same way and is IMHO a bit more ergonomic. It didn't exist back when that commit was made (we weren't using parse-options yet). So perhaps the documentation for --template ought to point people in that direction. But probably we should still mention the "empty string" behavior in all of the other spots, since as you mentioned it works equally for the config and environment variables (where is no "--no-" equivalent). -Peff
