RE: Suggestion: Enhance git init with Language-Specific Templates

[<rsbecker@nexbridge.com>]

On March 5, 2025 5:43 PM, brian m. carlson wrote:
>On 2025-03-04 at 11:49:14, Tech Kenya wrote:
>>
>>
>> I would like to propose an enhancement to git init that allows users to specify a
>language or framework when initializing a repository, automatically applying an
>appropriate .gitignore template.
>>
>> Proposal
>>
>> Introduce a flag to git init that enables users to initialize a repository with a
>predefined .gitignore based on the project's language or framework. For example:
>>
>> git init --golang
>> git init --python
>> git init --node
>>
>> This would generate a .gitignore file using well-established templates, such as
>those from Toptal's Gitignore Generator
>https://www.toptal.com/developers/gitignore/ or GitHub's official .gitignore
>repository.
>
>I think this is an interesting idea, but unfortunately, I think it's going to be practically
>difficult to implement.  You've mentioned three very common languages, but there
>are a lot of programming languages and even more compiler environments, and it
>wouldn't be practical for us to try to support them all.
>
>For instance, I use Neovim, and the version I'm using ships with 693 different syntax
>files, which means that there's about 693 different programming languages
>supported.  I was recently exposed at work to some languages that I'd never heard
>about before and which are not supported by Neovim, and presumably those users
>would also want similar functionality.
>
>That is compounded by the fact that there are a lot of OS- and environment-specific
>configuration.  As an example, a C project on macOS might want to ignore XCode-
>related files, but for a project that's only on Linux, that wouldn't be necessary.
>Similarly, that C project might create shared libraries that should be ignored, but
>those might end up with any of `.so`, `.sl`, `.dylib`, or `.dll` extensions.
>
>You mentioned some possible sources for this configuration, but we try not to
>prioritize specific outside projects.  So just because GitHub is widely used and some
>GitHub employees contribute to Git doesn't mean we give it special precedence or
>privileges, and we wouldn't want to prioritize their specific collection (or any other),
>nor would be want `git init` to attempt to make a network connection.  We also
>don't want to maintain this collection ourselves, since it's very project specific.
>
>What Git _does_ provide is a way to create a template of objects that should be in
>the `.git` directory using the `--template` option.  It's possible to create a template
>that contains an initial commit with a `.gitignore` file.  I personally would not
>recommend this approach, since it will not work gracefully with alternate ref
>formats or hash algorithms, but it is an option for people who want to use it.  This
>was in common use for setting up the default branch name before `git init` added
>the `-b` option and it's related config, so it is well tested.

One way to deal with this is to add language-specific descriptors. What I did in my
own front end is to provide a set of regex patterns that define the relevant portions
of the languages and extensions. This allows my end-users to add their own languages
and leave me out of it completely. It might be workable if we have a quantified
extensible language structure for this. Otherwise, this might be DOA.

--Randall