7 ms·

Git: ignore file lines

66 points by ephexeve 12y ago

oellegaard 12y ago
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
- jpitz 12y ago
  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 12y ago
    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 12y ago
      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.
- peedy 12y ago
  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 12y ago
    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 12y ago
      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.
- Mithaldu 12y ago
  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 12y ago
    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 12y ago
      That still means i need to trigger a rebuild on every pull/checkout/reset. Only a marginal improvement, really.
      - chrisan 12y ago
        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?
  - zak_mc_kracken 12y ago
    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.
- xorcist 12y ago
  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.
- zak_mc_kracken 12y ago
  You're missing the point.
daigoba66 12y ago
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.
- oneeyedpigeon 12y ago
  Github's app [1] does much the same thing, but (IMO) with a much nicer interface. And it works with any git repo, not just one with a github remote. [1] https://mac.github.com/ https://mac.github.com/
- colinbartlett 12y ago
  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.
  - JamesSwift 12y ago
    I've defaulted to this for some time now, and have no issues with keeping my own smattering of me-specific configuration overrides. Plus, there are a couple other times when being able to work through the patching interface is a handy skill to have.
  - Estragon 12y ago
    Magit in emacs is great for this functionality. It will even add just the selected region of the diff.
- pluma 12y ago
  I actually prefer `git add -i` if I want more fine-grained control like that.
  - pimlottc 12y ago
    git add -i is a good idea, but the interface is just /atrocious/ - confusing, poorly worded, visually unattractive and hard to read (dark blue text is not very user friendly on a black background).
darkhorn 12y ago
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.
manojlds 12y ago
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.
InfiniteRand 12y ago
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_ 12y ago
  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'.
joaomsa 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      Then you've been lucky. Although if you show others on your team this approach, I think something bad is guaranteed to happen eventually.
rhythmvs 12y ago
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
im3w1l 12y ago
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.
kivihiinlane 12y ago
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.
amelius 12y ago
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.
nivla 12y ago
Ignoring files are easy but ignoring selective lines? Wouldn't that conflict with the file's hash in Git's database?

66 points by ephexeve 12y ago

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

jpitz 12y ago
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 12y ago
  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 12y ago
    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.
peedy 12y ago
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 12y ago
  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 12y ago
    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.
Mithaldu 12y ago
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 12y ago
  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 12y ago
    That still means i need to trigger a rebuild on every pull/checkout/reset. Only a marginal improvement, really.
    - chrisan 12y ago
      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?
- zak_mc_kracken 12y ago
  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.
xorcist 12y ago
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.
zak_mc_kracken 12y ago
You're missing the point.

daigoba66 12y ago

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.

oneeyedpigeon 12y ago
Github's app [1] does much the same thing, but (IMO) with a much nicer interface. And it works with any git repo, not just one with a github remote. [1] https://mac.github.com/ https://mac.github.com/
colinbartlett 12y ago
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.
- JamesSwift 12y ago
  I've defaulted to this for some time now, and have no issues with keeping my own smattering of me-specific configuration overrides. Plus, there are a couple other times when being able to work through the patching interface is a handy skill to have.
- Estragon 12y ago
  Magit in emacs is great for this functionality. It will even add just the selected region of the diff.
pluma 12y ago
I actually prefer `git add -i` if I want more fine-grained control like that.
- pimlottc 12y ago
  git add -i is a good idea, but the interface is just /atrocious/ - confusing, poorly worded, visually unattractive and hard to read (dark blue text is not very user friendly on a black background).

darkhorn 12y ago

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.

manojlds 12y ago

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.

InfiniteRand 12y ago

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_ 12y ago
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'.

joaomsa 12y ago

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 12y ago
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 12y ago
  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 12y ago
    Then you've been lucky. Although if you show others on your team this approach, I think something bad is guaranteed to happen eventually.

rhythmvs 12y ago

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

im3w1l 12y ago

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.

kivihiinlane 12y ago

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.

amelius 12y ago

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.

nivla 12y ago

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