Re: git init with template dir

[Junio C Hamano <gitster@pobox.com>]

Alex Cornejo <acornejo@gmail.com> writes:

> Junio C Hamano <gitster <at> pobox.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 ...
>
> 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 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.