Hi Josh,
Josh Triplett wrote:
> On rare occasions, a project may need to store and version a .git
> directory in a git repository. For instance, a project that interacts
> with git repositories may need test cases. Or, a project using git to
> store backups may also want to back up git repositories. `.git` is the
> only filename that git can't transparently store and version.
My take on this might be a bit surprising, but it's probably worth
spelling out anyway: Git is first and foremost a source code
management tool, and ".git" directories are not a good interchange
format, so while I have sympathy for this use case, I do _not_ think
that Git should make changes that hurt other use cases in order to
support it.
Instead, I recommend doing one of the following, in order from most to
least preferred:
1. Make the test case run git commands to create a Git repository.
This makes it obvious what the test is trying to do, without
having to deal with unrelated details also recorded in ".git".
This is what Git's test suite does, for example.
2. Check in a fast-import file and use "git fast-import" to make a
Git repository out of it.
3. Check in a "git bundle" file and use "git clone" to make a Git
repository out of it.
4. Check in an archive file (e.g., tar) containing a .git directory.
(I consider this preferable over checking in a .git directory
directly because it prevents a user from accidentally "cd"-ing
into it and running git commands within the checked-in repository
that they intended to run in the top-level repository. That seems
especially worth preventing because the checked-in repository can
contain git aliases and other settings such as core.pager that
cause automatic code execution, as you mentioned.)
Thanks and hope that helps,
Jonathan
