0

I have version control with Git over the configuration files of a server. A file (namely app.ini from Gogs) requires the database user and password to be stored in cleartext.

Is there any way to transparently commit the file without the password being visible to other users of the Git repository? I could use git add --patch while staging, but I want it to be transparent so the other users (and I) don't have to pay attention to do it in every commit.

pdacostaporto
  • 21
  • 2
  • 3
    The typical way is to not commit those files to your repository at all, but instead commit a template. The actual configuration file should usually reside only on the servers/machines that require them. The eventual next question you come up with is how to ignore local changes because one develop usually debug against some other configuration and the same answer applies. – Lasse V. Karlsen Apr 28 '17 at 06:53
  • You could delete the password and git-add the file in a pre-commit hook. Or just raise an error to make the commit fail if the password is tracked. But you still have to pay attention in case the file is renamed or the hook is not installed in a new cloned repository. – ElpieKay Apr 28 '17 at 07:08
  • @LasseV.Karlsen: I understand that maybe version control or Git are not the appropiate way of managing configuration files of a server, but its the way our team does it because of the possibilities it brings for change communication and discussion. I really want the actual configuration to reside in the repo, with the sensitive part obscured. – pdacostaporto Apr 28 '17 at 14:23
  • i think it may be something like [this](http://stackoverflow.com/questions/6557467/can-git-ignore-a-specific-line) but I would want the filter to be attached to the repo, not to be part of my personal Git configuration. – pdacostaporto Apr 28 '17 at 14:35

1 Answers1

0

As Lasse V. Karlsen suggested, you can commit a template (e.g. replace your password with stars).

Then use git update-index --assume-unchanged app.ini to let git ignore all further changes to this file. After committing, you can simply insert the real login data back and git status won't show you any changes. So you will never push the password by accident.

0xpentix
  • 732
  • 9
  • 22
  • I don't think it solves the problem because I expect the file to have changes in the future. – pdacostaporto Apr 28 '17 at 13:58
  • Then you would it to the index again using `--no-assume-unchanged`, write your changes, commit them and remove it again from the index before inserting your real login data again. – 0xpentix Apr 28 '17 at 14:45
  • It's OK as workaround, but still a distracted user can make a mistake. – pdacostaporto Apr 28 '17 at 14:59
  • You mean by accident? This would mean that the distracted user "by accident" would have to call `git update-index --no-assume-unchanged`... And `update-index` is not a **that** often git command. – 0xpentix Apr 28 '17 at 15:01
  • The problem here is that there is no safe 100% way to ask git to do what you want it to do. Either you ask git to track the file, or you don't. If you ask it to track the file, any local changes will be reported by `git status`, and any `git add .` will add that file. The "typical" way I described in my comment to the question is not just "this is how most people do it", it's basically "this is the only way to do it" because any other solution requires each and every developer to be diligent when committing. – Lasse V. Karlsen Apr 28 '17 at 22:58
  • @Lasse V. Karlsen No, after removing it from the index using `git update-index --assume-unchanged`, `git status` won't show changes anymore and even `git add -f` won't add the file to the staging area. Git kind of forgets about this file... – 0xpentix Apr 29 '17 at 04:35
  • On your machine, yes, but that assumption isn't propagated around to everyone that works on the same project. – Lasse V. Karlsen Apr 29 '17 at 12:12