13

Problem

Consider this file tree as my development repository.

 - foo/
   - .git/
     - [...]
   - bar/
     - backupclient.py
   - supersecretstoragecredentials.ini

For development, supersecretstoragecredentials.ini needs to be filled in with valid credentials - while I still have to keep a clean version of it in the repository so that other users can easily set their credentials.

Possible solutions

  1. .gitignore supersecretstoragecredentials.ini and create a supersecretstoragecredentials.ini-example,
    1. instruct the user to copy supersecretstoragecredentials.ini-example to supersecretstoragecredentials.ini.
  2. Add an overriding config file location in backup.py which is ignored by git, e.g. supersecretstoragecredentials_local.ini.

As kan pointed out, these two solutions are similar but not entirely the same, workflow-wise.

are there any other alternatives? Does git possess some kind of functionality to assist with this kind issues?

Community
  • 1
  • 1
joar
  • 15,077
  • 1
  • 29
  • 54

5 Answers5

13

Check in the supersecretstoragecredentials.ini file with some placeholder values and then

git update-index --assume-unchanged supersecretstoragecredentials.ini

Git will not track future changes to this file.

You can reset this using 

git update-index --no-assume-unchanged supersecretstoragecredentials.ini
dexter
  • 13,365
  • 5
  • 39
  • 56
  • 1
    The only problem with this solutions is that a `git pull` by another user will create merge conflicts. Still, it's a great solution as long as your consumer base is limited. – joar Nov 29 '11 at 13:02
  • @jwandborg good point to note! only proposed this solution since this file is used to store local credentials.. – dexter Nov 29 '11 at 13:46
5

What you are describing in Option 1 is basically covered by the smudge step of a content filter driver.

filter driver

You have the two options presented in the "How to work on a drop-in library?" question.

the smudge script would take your supersecretstoragecredentials.ini-example (versioned), copy it as a supersecretstoragecredentials.ini (not versioned, ignored by Git), and fill its values from another source.

But beside the technical aspect of how you will implement your policy, the main measure is to make sure your secret values aren't store in a Git repo at all, but are comming from another referential.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
3

I use your solution (your two solutions are the same, only file names differ). Do you have any issues with it? What kind of functionality would you expect?

Also, there is a more interesting solution

git update-index --assume-unchanged supersecretstoragecredentials.ini

Hopefully it's what you want. However it would fail if the upstream changes the file and you are pulling the change (not completely sure is it good or bad).

kan
  • 28,279
  • 7
  • 71
  • 101
1

Something that I am trialling at the moment is git-secrets.

https://github.com/awslabs/git-secrets

It hooks into the git commit process and checks for patterns that look like credentials that should not be checked in.

You have to ensure that it is installed on each developer's system and configured for each git repository. This can be achieved easily enough if you integrate a check into the build process.

Stephen Souness
  • 272
  • 1
  • 3
1

In my experience, after having tried all options listed in your question and in the answers so far, your #2 option has proven the simplest and cleanest. It solves the problem reliably, with the least magic, and is easiest to understand. It is boring in the best way.

Aristotle Pagaltzis
  • 112,955
  • 23
  • 98
  • 97