[oellegaard]

You should establish a proper pattern for storing credentials instead. Many people use environment variables, but you can also use an external configuration file.

Another simple pattern used a lot in django:

try: from local_settings import * except Exception: pass

Then put any variable you want to override in local_settings.py and put local_settings.py in .gitignore

[Mithaldu]

Ok, here, have a better example:

I contract for a company which has set rules for their stuff. Trying to change these rules would be an amount of effort similar to becoming CEO, starting out as a deckswabber.

One of their project is a web app. It has an .htaccess file. In production it is configured to run like this:

    Addhandler fcgid-script .fcgi

However in development i want it to run like this:

    Addhandler cgi-script .fcgi

Normally you'd just put the entire file on ignore with --assume-unchanged, but that doesn't work well, since the file also contains other bits of configuration that are important for the app, and get changed fairly frequently.

OP's tool is perfect for this kind of situation.

[zak_mc_kracken]

Another example: IDE configuration settings.

Projects sometimes check in an IDE formatting file settings to ensure that all developers use the same formatting. There are a couple of times where I wanted to add my own little formatting detail (which didn't conflict with the project's) but couldn't because doing so would mark that file modified and force me to remember to undo my changes before each push.

With the hack from the article, I have now a working solution out of this.

[chrisan]

FWIW we moved to a .htaccess.dist setup and our build tool would populate the actual .htaccess file with either of your examples depending if you were building for development or production.

.htaccess is ignored while the .htaccess.dist template is part of the reop

[Mithaldu]

That still means i need to trigger a rebuild on every pull/checkout/reset. Only a marginal improvement, really.

[chrisan]

We only need to rebuild that file when we want to change it, which doesn't happen often. It's been at least a year since I changed my local dev copy for our main project and has survived many pulls/branches/resets

What kinda stuff are you putting in .htaccess that changes so often?

[_ikke_]

What happens if someone accidentaly committed the Addhandler cgi-script .fcgi change?

Note that --assume-unchanged means you are promissing to git that the file hasn't changed, so it doesn't have to lookt at it every time you invoke git status (for performance reasons).

When you break that promise, git will complain, just like you said.

[oellegaard]

Actually this is a good example. You should not have apache configuration in your .htaccess file. It should be in the actual apache config.

[xorcist]

> Trying to change these rules would be an amount of effort similar to becoming CEO

That's not even remotely possible.

[jpitz]

If you read what TFA says:

    "Of course this is a stupid example, you would probably
     put the username, password and other important stuff in
     another file, say a config file, but let’s assume that
     this is not possible, or somehow this variable cannot be
     else where."

[oellegaard]

I'd still argue that this is an anti-pattern. If you find yourself in a situation where you want to leave out a line from git in the middle of a file, you should reconsider the structure of your code/project/whatever.

[oneeyedpigeon]

Agreed. The article isn't particularly useful because it essentially says "this is how you solve a 'problem' that I'm only going to demonstrate by giving an example I immediately dismiss" and not explaining the type of situation in which this might be useful. Every time I've found myself in a similar situation, the problem has not been that git doesn't allow me to pretend that certain lines in a file don't exist, it's been that my design has been lacking.

[zak_mc_kracken]

You're missing the point.

[peedy]

If you're on a django project, most probably you're using virtualenv. I had a habit of just putting environment variables in the postactivate script.

[pyre]

E.g. I build a new virtualenv from scratch for each deploy, so that would mean that the postactivate script would need to be accessed from somewhere by the build process.

[peedy]

I was talking about local dev install where you can activate postactivate script is run after you source activate or call workon. In prod, you will not be activating the env but running executables directly from the env.

ie, your process manager will call /path/to/env/bin/gunicorn and in this case, you'll have to configure the env variables here (in the process manager (supervisor)) config.

[xorcist]

Why would you do that? Store configuration in a checked-in directory?

Do you expect to develop on your production systems?

Do you also store databases in the same directory?

I can not think of a possible use case for this, but I guess there must be since this at least someone seems to recognize it.