2

I want to commit an initial version of the file to Git and then disallow modifications of that file. How can that be done? I have tried: - adding the file to .gitignore after the initial push (but that wont work because the file is already tracked). - git rm -rf --cached , but that deletes the file from the repository on next commit.

Luka Špoljarić
  • 988
  • 1
  • 10
  • 23
  • You can't protect a single file, or even modifications to a locally cloned repo as far as I know. You can protect branches on a remote however. – evolutionxbox Sep 13 '18 at 12:41
  • 2
    `.gitignore` cannot help here. You can write a local `pre-commit` [Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#_client_side_hooks) that rejects the commit if the desired file is modified. A local Git hook is not copied to the server and does not prevent other developers modify the file. A server-side hook is more effective. – axiac Sep 13 '18 at 13:36
  • "I want to commit an initial version of the file to Git and then disallow modifications of that file"—that's not a natural thing for Git to do. You're fighting against the tool. Why do you want to do this? Is it a configuration file? There are well-established patterns for handling this kind of thing. – ChrisGPT was on strike Sep 13 '18 at 13:49
  • This is not something git can do, or at least I don't know how, but you can do it in gitlab. I think there's something similar in git lfs, have a look here: https://github.com/git-lfs/git-lfs/wiki/File-Locking – ErniBrown Sep 13 '18 at 13:53
  • @axiac Yes I agree, the only way to do the desired thing is to use a server side git hook. There is also a gitlab feature that provides the same thing but im not using gitblab atm. Thx for then input every1. – Luka Špoljarić Sep 13 '18 at 14:14

2 Answers2

1

If you are considering using .gitignore for that I'm assuming you're ok with configuring every local repository for this. If so, you could use git update-index --skip-worktree path/to/file. This will prevent changes to the file from being commited and/or tracked.

Danilo Souza Morães
  • 1,481
  • 13
  • 18
  • Yes, but then every programmer would NEED to execute skip-worktree command localy, if someone forgets to do it, he will stomp our changes on next push (to be clear this is the way we are doing it at the moment, but i was just wondering is there a better way) – Luka Špoljarić Sep 18 '18 at 06:23
1

I met the same problem in programing. My project have a file named setting.cfg. But my collegues should change it a little for his own environment. We want to share the setting.cfg file and change it without pushing to the remote repository.

Finally, we created a file named setting.cfg_bak, and ignore the setting.cfg:

git rm setting.cfg
echo "setting.cfg" >> .gitignore`

If you want to use the file, you should copy setting.cfg_bak to setting.cfg, and modify setting.cfg for you own needs. After this, the modification will not be pushed to the remote repository.

ramwin
  • 5,803
  • 3
  • 27
  • 29
  • That is what we are doing at the moment, but im trying to figure out can we somehow automate it without the need to copy/paste. – Luka Špoljarić Sep 14 '18 at 08:34
  • why would you version a file called setting.cfg_bak if you can commit setting.cfg and `git update-index --skip-worktree setting.cfg`? This way every user can update their own copy of the setting.cfg without worring about commiting that change. My answer seems like exactly what you asked for – Danilo Souza Morães Sep 14 '18 at 20:06
  • It won't work if you clone the repository and changed it. – ramwin Sep 17 '18 at 04:01
  • In this case, everyone who cloned the repository should execute the command. It isn't easier nor simpler than copy the `setting.cfg_bak` file. – ramwin Sep 17 '18 at 04:05
  • It even may be even more dangerous if someone changed the file and forgot to execute the command. – ramwin Sep 17 '18 at 04:07
  • I hadnt understood the requirement properly. In that case I agree the best option is to have a bak file in the repository, just like .env files and on the server you set that file manually and have the code look for both files, always prioritizing the one thats not versioned. So say you want to distribute a db.config file: you add to git mydb.config with localhost configs and have you code first look for a db.config and if it doesnt find it, look for mydb.config. That way you could still have a working version by just cloning and would still have a unique version on the server – Danilo Souza Morães Sep 18 '18 at 17:48
  • Here is a scenario. You and your colleague are working in a project. It contains a config file named `setting.cfg`, there is lots of configuration in common for you and your colleague, but only online `host=` should alter for different computers. So you created a basic config file with `host=` and pushed it to the remote repository. Evenryone who clone the project should have this file and change this line but should never commit this change to remote repository. – ramwin Sep 19 '18 at 01:27