0

I'm in a situation with a git repo where I want to keep a file unchanged, unless the developer specifically knows what they are doing when they change it.

We have a Drupal website in a repo with a custom robots.txt that we don't want changed. Updating Drupal core involves unpacking a tarball. That means that our custom robots.txt would get replaced with the stock Drupal robots.txt. Since Drupal core updates are accepted wholesale (they are mostly security updates), a developer who is perhaps somewhat careless would accidentally overwrite our robots.txt.

This isn't something you would pick up on in a Pull Request, because there are dozens of files that change in a core update, and you're not going to review all of them. I posted another question, but the answers involved repo/environment changes that are local only, and don't get tracked in the repo. I've done some more research, and this is what I've discovered so far:

  • skip-worktree is a local property only; not tracked.
  • assume-unchanged is a local property only; not tracked.
  • .gitignore -- I tried untracking the file, ignoring it, and then --force adding it. When I made changes, git still saw them. This is not a solution.
  • hooks are not tracked in the repo. You can configure them to be tracked, but that involves setting up the local environment for them to start working, and if we're going to do that, why not just set up skip-worktree or something else instead.

Is there presently no way to stop a file's changes from from being committed (outside of explicit/extra steps, like a switch) within the repo itself, outside of doing extra local configuration?

The reason I'm posting this question is because I am trying to give my manager a definitive "No, we cannot track this information in the repo. We are going to have to do extra configuration on developer's environments."

I'm using git 2.12.0.windows.1 in git-bash on windows.

Community
  • 1
  • 1
user151841
  • 17,377
  • 29
  • 109
  • 171
  • 1
    You can't ask git to ignore an already tracked file in such a way that it is left alone in all cases. Any reason why you don't have a proper deployment script that would handle these things? – Lasse V. Karlsen Apr 25 '17 at 20:31

2 Answers2

2

If you're hosting your own repo (as opposed to using, say, github), you can write a pre-receive hook on the central repo to detect this. It would check for pushes that introduce commits that modify the guarded file and reject them.

This is a bit sub-optimal because it doesn't detect the situation until a developer has finished her work in her local repo, and it requires somewhat esoteric git-fu (like rebase -i and commit --amend) to repair the local commits before the push can be retried.

Matt McHenry
  • 20,009
  • 8
  • 65
  • 64
  • We're not hosting our own repo :/ Our hosting provider also provides the repository server. – user151841 Apr 25 '17 at 18:43
  • Speaking purely technically, is it safe to say that this solution also is not tracked in the repo, as it only resides in the server? That, if the repo were pushed to a new remote, the `pre-recieve` hook would not go with it? – user151841 Apr 25 '17 at 20:14
  • @user151841 correct, this approach is *not* tracked in the repository, it would just be part of the configuration of the server that hosts the "central" repo. If your workflow doesn't have one central server, it's a non-starter. – Matt McHenry Apr 26 '17 at 00:38
0

The answer is No.

There is no way to stop a file from being normally changed, and tell git to track that status.

All solutions involve either local environment settings or settings on the remote repo.

user151841
  • 17,377
  • 29
  • 109
  • 171