Re: Idea regarding GIT

On 2026-01-12 at 02:53:49, Krzysztof Zabłocki wrote:

Dear all,
I'm emailing to suggest feature for git. It can be useful for ppl working
with pipelines and having extensive personalized configs. I propose adding
new configuration file (or parameter in .gitconfig) .gittemplates. Files
listed in there had to be indexed before adding them to that file, otherwise
it would work like .gitignore, but difference is if file was added git will
not track changes in it and won't commit them. It can be useful with .env
files, using this feature their empty, template version can be committed and
frozen where local version can be edited. Same with configs requiring local,
machine specific paths. Now there is need to keep template version committed
with different name and proper one recreated locally and ignored which adds
extra work each time.

Yeah, you're describing the FAQ entry listed at
https://git-scm.com/docs/gitfaq#ignore-tracked-files.  The rationale
that's given is this:

    The reason is that if Git needs to overwrite this file, such as
    during a checkout, it doesn’t know whether the changes to the file
    are precious and should be kept, or whether they are irrelevant and
    can safely be destroyed.

Even with a `precious` attribute for ignored files, presumably there is
some point at which you want to update the file.  For instance, maybe
the template contains a new, mandatory configuration setting that you
need for your software to work.  However, Git can't possible know when
that situation occurs.

In the case of your `.gittemplates` approach, you have no template file
on disk, only the filled-in file, so there's no way to actually rebuild
the file off the new template.  Your only choice would be to blow away
the file on disk and reset it.  However, with the existing approach, you
can simply run a script (which could even be done in a `post-checkout`
hook if you like) to rebuild the ignored file from the template file,
including whatever information you need or merging the existing data.

It also becomes very complex because Git is absolutely not designed to
have tracked files that are not written into the working tree, so things
like `git reset --hard` would have ambiguous behaviour: do you want to
reset the file to its original state or do you want to preserve it?  If
you want to preserve it, how do you do a full reset of the working tree
to its original state?

At work, we have a standard script for setting up the repository[0], so
it's very easy for anyone to do anything necessary, like generating
these kinds of files or running database migrations.  And again, this
can be done automatically in a hook.

[0] https://github.com/github/scripts-to-rule-them-all
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA