2

I have a configuration file config.env in my repository. My code makes modifications to this file based on some environment parameters through a shell script.
What I wish is to not track changes to this specific file and continue committing new changes to the code while continuing to pull the original config.env, even though it might be changed while running the code. How can I make that happen?


The reason I have posted this question again as the popular answer of using git update-index --assume-unchanged is explicitly rejected by the documentation.

Vishakha Lall
  • 1,178
  • 12
  • 33
  • add it to a `.gitignore` file => it wont be commited again. or before each commit you can `checkout your_file` to keep the last version => this i sway more dangerous – Ivan Jan 29 '20 at 16:47
  • 1
    You will have to instruct git to ignore changes to it using `git update-index --assume-unchanged `. This will need to be done every time you clone the repository, and possibly even if you check out a different branch. I don't use this command so you'll have to read up on it. Contrary to other comments you're bound to get here, adding the file to `.gitignore` will not work, as you've probably already tried. That's just for avoiding `git add` to add it to begin with. – Lasse V. Karlsen Jan 29 '20 at 16:48
  • 1
    However, you would be better off to adopt the normal pattern to deal with configuration file. Commit a template, like `config-template.env` or `config.env.template`, and add the real configuration file to .gitignore, then remove it from the repository. This allows you to make changes to the template and commit those, while keeping the actually used file out of the repository. If you can, you can even add a build or when-executed step to make a copy of the template if the used file is missing on disk. – Lasse V. Karlsen Jan 29 '20 at 16:50
  • 2
    Does this answer your question? [How do I configure git to ignore some files locally?](https://stackoverflow.com/questions/1753070/how-do-i-configure-git-to-ignore-some-files-locally) – Lasse V. Karlsen Jan 29 '20 at 16:52
  • Does this answer your question? [Can I 'git commit' a file and ignore its content changes?](https://stackoverflow.com/questions/3319479/can-i-git-commit-a-file-and-ignore-its-content-changes) – phd Jan 29 '20 at 17:38
  • https://stackoverflow.com/search?q=%5Bgit%5D+track+config+file+ignore+changes – phd Jan 29 '20 at 17:38
  • 1
    Please do not encourage people to use `git update-index --assume-unchanged`. That information is wrong and [the Git documentation](https://github.com/git/git/blob/14c781fcd47c8d8b771cd189f43840f355b19512/Documentation/git-update-index.txt#L552-L567) now explicitly warns against it. – bk2204 Jan 30 '20 at 01:18
  • I had certainly read about not using ```update index``` as indicated in other answers, which is why I posted it again. – Vishakha Lall Jan 30 '20 at 04:48
  • @LasseV.Karlsen thanks for your inputs. Indeed, I had already tried .gitignore and that didn't prove to be efficacious. – Vishakha Lall Jan 30 '20 at 04:51

1 Answers1

0

The best way to do this is to create a template file (say, config.env.template) and store that in the repository and ignore the actual file (config.env) you modify on your local system. That way, it's possible to preserve the changes to the template file in the repository yet have your local modifications.

Note that git update-index --assume-unchanged, while commonly recommended, doesn't work as intended and is not supposed to be used for this, according to the Git documentation:

Users often try to use the assume-unchanged and skip-worktree bits to tell Git to ignore changes to files that are tracked. This does not work as expected, since Git may still check working tree files against the index when performing certain operations. In general, Git does not provide a way to ignore changes to tracked files, so alternate solutions are recommended.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • Hmm, I suppose there's no other way then. Thanks! Also, I had read about not using ```update index``` which was the accepted answer in other similar questions which is why I posted this again. – Vishakha Lall Jan 30 '20 at 04:49