git init with template dir

I was surprised to see that when using git-init, if the template folder is itself a symlink, then the contents of the template is NOT copied to the resulting git repository, but instead each individual file is symlinked.

For my particular use case, this is undesirable (since if I am not careful, then when I change the hook of one git repo, it actually changes the hooks of all other repos too). It is easy enough for me to work around this (i.e. by instead pointing my gitconfig to use a template dir which is not a symlink), but I was wondering weather this is a feature folks use (and for what end), or if this is unintended behavior.

Furthermore, would a patch be welcome that either disables this feature through an option (or perhaps permanently by just copying the contents of the symlinked folder instead of creating individual symlinks), or am I the only git user that was surprised by this behavior and wanted to disable it?

- Alex

Alex Cornejo <acornejo@gmail.com> writes:

Hmmm, I do not seem to be able to do this, though.

        $ ln -s $HOME/g/share/git-core/templates /var/tmp/git-template
        $ cd /var/tmp
	$ git init --template=/var/tmp/git-template new
        $ find new/.git -type l
        ... nothing ...

That you had to predicate "this is undesireable" with "For my particular use case" tells me that other people may want to see that these things shared and automatically receive updates when the originals in the temporate directory are updated, which makes it sound like a "feature" not an "unintended behaviour", at least to me.

Junio C Hamano <gitster <at> pobox.com> writes:

Thanks for your prompt response Juno.

That make sense. The fact that you were unable to reproduce this tells me that there is probably something fishy/unexpected with the environment in which I tried this (which is not too surprising, given that I was doing it inside a linux container, inside a virtual machine, where both of these were setup using a scripts which ultimately failed after the git init step, due to the symlink behavior I described, but most likely this is my own fault). I should have tried to reproduce this on a clean slate before posting this question.

Thanks again,

Alex

Alex Cornejo <acornejo@gmail.com> writes:

I wouldn't call that your "fault". After all, as more people want to run Git in different environments, we would want to make sure Git runs correctly for them.

I quickly re-scanned what we do inside "git init" and how we populate the repository from templates. This happens all in builtin/init-db.c:

 - copy_templates() does opendir(), so it should not have mattered
   that I used /var/tmp/git-template that is a symbolic link to a
   real location in my quick reproduction attempt;

 - it calls a recursive copy_templates_1() with that directory
   handle it opened for the template directory.  Each entry it finds
   are inspected and

   - real directories are recursed into;
   - files are copied; and
   - symlinks are recreated.

So if I instead made a new directory /var/tmp/git-template/ and then populated it with a bunch of symbolic links e.g. hooks, description, etc., that points at their real location, I would have seen that the resulting repository populated with symbolic links.

And I think that is an expected behaviour.

But if "git init" made bunch of symbolic links only because it was given a symbolic link to the real directory via its --template parameter, that _is_ unexpected, and we may want to dig deeper to correct it.