I have a central repository with a subset of files that I want to protect from been changed (by pushing) from another users. If I add this files to .gitignore they would not be cloned. Is it possible to give the ability to clone all files, but after cloning add some of them to .gitignore on the client side?
A:
I initially thought about a filter driver (see Pro Book), which would:
- on the smudge step save your files content
- on the clean step would restore your files content.
But that is not a good solution since those scripts are about stateless file content transformation (see this SO answer).
You can try enforcing a save/restore mechanism in hooks (see the same SO answer), but note that it will be local to your repo (it will protect your files in your repo only, hooks aren't pushed)
You can also use:
git update-index --assume-unchanged file
See "With git, temporary exclude a changed tracked file from commit in command line", again a local protection only. That will protect them against external push to your repo ("import"), but if you publish them ("export"), than can be modified on the client side.
VonC
2010-07-29 06:54:04
Thanks. I know about git update-index --assume-unchanged, but it is applied only on the client side.I know also about hooks, but they are not cloned from the central repo.
andrexus
2010-07-29 08:54:18
@andrexus: I know: filter driver is the only pushable solution, but it will require bending the smudge script to force it to know about the path of the relevant files (to save/restore), whereas it should only know about the content of the files...
VonC
2010-07-29 09:03:51
A:
Is there a specific reason why Git must itself be the answer to this?
How about making the files read-only, and dictating as policy that these files shouldn't be pushed?
Sometimes a technological solution is not the simplest way.
If somebody does push changes to these files, these changes can always be reverted.
mfontani
2010-07-29 07:54:52