Can git ignore a specific line?

Question

If your file is of a specific type, you can declare a content filter driver, that you can declare in a .gitattributes file (as presented in the "Keyword expansion" of "Git Attributes"):

*.yourType filter=yourFilterName

(you can even set that filter for a specific file, if you want)

Implement:

• yourFilterName.smudge (triggered on git checkout) and

    git config --global filter.yourFilterName.smudge 'sed "s/isPhoneGap = .*/isPhoneGap = true/"'
  

• yourFilterName.clean (triggered on git add)

    git config --global filter.yourFilterName.clean 'sed "s/isPhoneGap = .*/isPhoneGap = false/"'
  

Your file would appear unchanged on git status, yet its checked out version would have the right value for isPhoneGap.

---

Note: in the comments, ohaal and Roald suggest to isolate the sed calls in a separate helper.sh script:

sed "s/isPhoneGap = .*/isPhoneGap = true/" "$@"

You can use

git update-index --assume-unchanged [file]

to ignore the changes of one file that you don't want track. I use this solution when I need to have a file in the repository but this file have some parts that change that I don't need track always.

When the file have changes that are important you have to do this:

git update-index --no-assume-unchanged [file]

Also, see the Git doc update-index for --[no-]assume-unchanged parameter.

When these flags are specified, the object names recorded for the paths are not updated. Instead, these options set and unset the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell git when you change the working tree file.

Gitx should let you commit or ignore individual lines (you may know that already), but you'd have to do that every time you commit. I think it would be better to have a config file per deployment target (you can version those), and some runtime parameter for however you are starting the server (like ./myserver --config=whatever.js).

Continuing https://stackoverflow.com/a/20574486/4935114, @Mike proposed to create a pre-commit hook which will grep in the staged files for the lines which one might want to ignore. The hook checks if those lines were staged. If so, it echos a warning and it exit's with code 1 so the commit process won't continue.

Inspired by @Mike's answer, I found myself using perhaps an improved version of his hook which automatically resets (with the -p flag) the specific line which we want to ignore.

I'm not sure this hook will work for a situation where you have many files with this line to be ignored, but this pre-commit hook looks for a changed in this line in a specific file buildVars.java. The hook script looked like this when I tested it on my machine.

#!/bin/sh

# this hook looks for lines with the text `var isPhoneGap = false;` in the file `buildVars.java` and it resets these lines to the previous state before staged with `reset -p`

if [[ $(git diff --no-ext-diff --cached buildVars.java | grep --count -e "var\ isPhoneGap[\ ]*=[\ ]*") -ne 0 ]]; then
    cat <<EOW
WARNING: You are attempting to commit changes which are not supposed to be commited according to this \`pre-commit\` hook
This \`pre-commit\` hook will reset all the files containing this line to it's previous state in the last commit.
EOW
    echo /$'\n'isPhoneGap$'\n'y$'\n'q | git reset -p
    # BONUS: Check if after reseting, there is no actual changes to be commited and if so, exit 1 so the commit process will abort.
    if [[ $(git diff --no-ext-diff --cached | wc -l) -eq 0 ]]; then
        echo there are no actual changes to be commited and besides the change to the variable \'isPhoneGap\' so I won\'t commit.
        exit 1
    fi
fi

Explanation

What I did was echoing a control sequences which searches for the regex isPhoneGap during an interactive reset process. Thus emulating a user who presses / to search for isPhoneGap, presses y when asked if he wants to discard this patch and finally presses q to exit the interactive reset.

The interactive reversed patch process is documented here: https://git-scm.com/docs/git-add#git-add-patch

---

NOTE: The above script assuming that the variable interactive.singleKey is false. If you configured yours to true, remove any $'\n' from the echo command right after the warning.

This is how you can kind of do it with git filters:

1. Create/Open gitattributes file:
   • <project root>/.gitattributes (will be committed into repo)
     OR
   • <project root>/.git/info/attributes (won't be committed into repo)
2. Add a line defining the files to be filtered:
   • *.rb filter=gitignore, i.e. run filter named gitignore on all *.rb files
3. Define the gitignore filter in your gitconfig:
   • $ git config --global filter.gitignore.clean "sed '/#gitignore$/'d", i.e. delete these lines
   • $ git config --global filter.gitignore.smudge cat, i.e. do nothing when pulling file from repo

Notes:
Of course, this is for ruby files, applied when a line ends with #gitignore, applied globally in ~/.gitconfig. Modify this however you need for your purposes.

Warning!!
This leaves your working file different from the repo (of course). Any checking out or rebasing will mean these lines will be lost! This trick may seem useless since these lines are repeatedly lost on check out, rebase, or pull, but I've a specific use case in order to make use of it.

Just git stash save "proj1-debug" while the filter is inactive (just temporarily disable it in gitconfig or something). This way, my debug code can always be git stash apply'd to my code at any time without fear of these lines ever being accidentally committed.

I have a possible idea for dealing with these problems, but I'll try implementing it some other time.

Thanks to Rudi and jw013 for mentioning git filters and gitattributes.

A content filter driver is not a good solution. You may be able to hide this line from git status/etc but it's not really being ignored. As soon as you change the value, your working directory will be marked dirty even though the change may not be visible.

If you really want this line out of version control, changing it to a command line argument or placing it in an ignored include or build file may be the only practical means.