Hi,
as more and more hooks are added to git, I would want to have the hook scripts, part of the per-repository configuration, itself in version control. If you look at CVS, the configuration there is also under version control (in CVSROOT). I can do this manually: after git-init-db, go into .git/hooks, do a git-init-db again, adding the hooks for version control, and commiting the initial version of the hooks.
But I get the feeling that the different hooks should be versioned on a file basis, and not on a directory/whole project basis. Here, I explicitly want to have the RCS/CVS way of versioning. [Another use case: a wiki site managed via a GIT archive, to be able to change the site offline. Here too, I would want to have versioning on a file basis]
Is there a way to "extend" git to allow for this kind of versioning? This needs multiple simultaneous checkouts of heads representing independent project parts (i.e. single files). There would be a GIT index for every such independent project part; the problem being that the checkouts should be done into the same directory.
So what is the best way to accomplish this? I have to use multiple index files (index1, index2, ...), allowing multiple independent branches could be checked out independently. Another extension would be kind of a "super-head" specifying multiple heads (SHAs) which are to be checked out simultaneously (via index1, index2...). It should be possible to create signed tags out of such super-heads.
Is this feasable?
Josef