As Nathan said, cleaning up those files (un-tracking them) is the smart move.
But if you must ignore tracked files (which is not the native Git way when it comes to ignoring files: Git only ignores non-tracked files), you can setup a process copying the content of files you want to ignore, and restoring on commit.
I initially believed that a smudge/clean process, that is a gitattributes filter driver could do the trick:
, where:
- the smudge process will make a copy of those files (when updating the working tree)
- some modifications take place during the build
- the clean step (during commit) will erase the files content with the copy made in step 1.
BUT, as stated in this post, that would mean abusing this stateless file content transformation by adding a stateful context (i.e. the full path name of the file being smudged/clean).
And that is explicitly forbidden by J.C. Hamano:
Although I initially considered interpolating “
%P” with pathname, I ended up deciding against it, to discourage people from abusing the filter for stateful conversion that changes the results depending on time, pathname, commit, branch and stuff.
and even Linus Torvalds had some reservations at the time about the all mechanism:
I have to say, I’m obviously not a huge fan of playing games, but the diffs are very clean.
Are they actually useful? I dunno. I’m a bit nervous about what this means for any actual user of the feature, but I have to admit to being charmed by a clean implementation.
I suspect that this gets some complaining off our back, but I also suspect that people will actually end up really screwing themselves with something like this and then blaming us and causing a huge pain down the line when we’ve supported this and people want “extended semantics” that are no longer clean.
But I’m not sure how valid an argument that really is. I do happen to believe in the “give them rope” philosophy. I think you can probably screw yourself royally with this, but hey, anybody who does that only has himself to blame
So the right place to add some kind of save/restore mechanism (and effectively ignoring any changes to a set of tracked files in Git) would be in hooks:
-
post-checkout: invoked when a git checkout is run after having updated the worktree. There you can run a script collecting all the files to ignore and saving them somewhere. -
pre-commit: you can run a second script which will restore the content of those files, before obtaining the proposed commit log message and making a commit.