
Git: ignore file lines - ephexeve
http://benmezger.me/post/109706270421/git-ignore-file-lines
======
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.

~~~
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?

------
InfiniteRand
I could see some uses for something like this. When I was working as a web
programmer, I often had to do a lot if dev-server type things. Since at least
one of the dev-server was often on my personal machine, it could often be a
very different beast than the production server.

I guess what this really is a matter of is configuration management, for
certain configurations you will have certain lines of code that will not
matter or that will confuse. While you can manage this within your code in
various ways (such as the #ifdef _DEBUG macro, etc.), it would be natural for
the VC to handle this.

For a general features, maybe you could either specify in a configuration
file, particular lines of a file or a regular expression to designate lines to
ignore or better yet to only apply to certain branch checkouts.

A nice feature to think about for my "one-of-these-days-I-will-make-a-beter-
version-control-system" file.

~~~
_ikke_
Why not just keep environment dependent settings in a separate file that is
not tracked? Then you have no problem with files that are 'half-tracked'.

------
daigoba66
In practice, I never use 'commit -a' or 'git add -A'. I prefer to use 'git
gui' to interactively stage files or just specific lines. This way I can be
sure of what is being committed.

~~~
colinbartlett
I use git add --patch

My teammates probably get tired of hearing it, but every time someone
erroneously commits some file or line I advocate its use.

~~~
Estragon
Magit in emacs is great for this functionality. It will even add just the
selected region of the diff.

------
rhythmvs
Not as generic a solution as ignoring lines on commit (whatever they may
contain or for whatever reason you want to hide them), but when it comes to
protecting credentials, crypto for arbitrary chunks of text comes in handy.¹
The fact that the encrypted string is being committed still might be a good
thing: as the code is run an error will be thrown as a reminder to either
decrypt or replace the string with one’s own creds.

¹
[https://packagecontrol.io/packages/Transcrypt](https://packagecontrol.io/packages/Transcrypt)

------
kivihiinlane
This is exactly what I was looking for few months back.

I was working on a rather large and very messy project back then. Project used
popular framework with very specific config files but previous dev choose to
ignore them most of the time so configurations were all over the place. I
didn't have much time to start looking more deeply into the git so I just
ended up using 'local-config' branch that had my environment specific configs
that I always rebased on top of master and deleted on commit. Wasn't perfect
solution but it worked.

------
joaomsa
Use the -p (--patch) flag, it works wonderfully for selectively marking blocks
for staging (git add -p), and selectively checking out changed files with (git
checkout -p).

~~~
michaelmior
My experience is that you'll quickly get burned if you do this for the use
case the OP mentioned. The goal is to keep different settings for a
development environment, not to just temporarily avoid committing. One day,
you'll inevitably forget and accidentally commit and push the changes you've
been carefully avoiding.

~~~
JamesSwift
I've not had that experience at all. For the times you know it would be
tedious to add/ignore all diffs manually, you can just use the 'a' or 'd'
commands to add or ignore for the remainder of the current file. I much prefer
using 'add -p' every single time I commit.

~~~
michaelmior
Then you've been lucky. Although if you show others on your team this
approach, I think something bad is guaranteed to happen eventually.

------
amelius
I'm still looking for an _elegant_ way to reject commits whenever a certain
pattern appears in one of the files to be committed (like "FIXME").

I know it can be done (tried it about a year ago), but it was too much of a
hassle to use it on all of my repositories.

------
im3w1l
I think I would handle it by making a "template file", scrubbed from the
secret sauce and a script that patches the template file into the real thing.
Only template file is checked into the repo.

------
darkhorn
You can put MySQL or MySQLi connection credentials in php.ini. Bu ignore line
will be useful for me too, I have a second connection to the reports database.

------
nivla
Ignoring files are easy but ignoring selective lines? Wouldn't that conflict
with the file's hash in Git's database?

------
manojlds
dotenv is a good way to handle such configuration problems -
[https://github.com/bkeepers/dotenv](https://github.com/bkeepers/dotenv)

Just .gitignore the .env file.

