3

Is there some cleaner way to make Git just ignore some of my changes and never commit them? .gitattributes:

config_to_be_deviated.xml filter=qqq

.git/config:

[filter "qqq"]
 clean = "perl -ne 'print unless /git_please_dont_look_here/'"
 smudge = (Q=$(mktemp) && cat > $Q && patch -s $Q < /tmp/pp && cat $Q && rm $Q)

The patch /tmp/pp adds my changes with "git_please_dont_look_here" in each line. Git removes all such lines before getting the file into repository and readds my changes when checking out it; I can continue adding and committing useful changes to config_to_be_deviated.xml, but changes in the patch will not be seen by Git.

Vi.
  • 37,014
  • 18
  • 93
  • 148
  • 1
    Making the patch to apply in reverse on "clean" is obvious fix and is not considered as answer – Vi. Feb 12 '10 at 02:50
  • Can you tell us why you want to be able to do this? it seems to go against what git and most version control systems are supposed to do... – Charles Ma Feb 12 '10 at 02:54
  • It may be useful when you have different build environment or there are some hardcoded paths in config files in repository. – Vi. Feb 12 '10 at 02:58
  • One other workaround I was applying was to make commits with "Do not commit this" in commit message and use a script that rebase & rollback & push & reapply that commits. – Vi. Feb 12 '10 at 03:03
  • Dude, use a branch. All this kong-fu is ridiculous. – abyx Feb 12 '10 at 15:06
  • Don't understand how the branch will help. The changes ("deviations") are not to be shared or integrated into the project someday. They are completely just for me. Note: it is git-svn case. – Vi. Feb 12 '10 at 16:03
  • To want local configurations that are not in the repository is not unreasonable. To play games with git to make it happen is. It's the wrong tool for the job, and some part of your brain knows it, too, or you wouldn't be asking if there is a better way. There is, but it doesn't involve git, really. It involves changing where your local configuration is stored. – Wayne Conrad Feb 12 '10 at 18:03

5 Answers5

2

It looks like this "filter" approach is the best suited for me.

Pros:

  1. No need to use custom scripts or special commands every time. One-time setup.
  2. No extra commits in history or in stash. Clean diffs and patches.
  3. Low rick of committing the wrong thing.
  4. Relatively easy to make minor deviations (like overriding some port number in config file), like simple sed script both for smudge and for clean.

Cons:

  1. Filter programs runs every time Git reads or writes the file, it can be slow (especially in Windows).
Vi.
  • 37,014
  • 18
  • 93
  • 148
1

Put them into separate file, ignore the file in git and hook it up to your build so it gets included?

stefanB
  • 77,323
  • 27
  • 116
  • 141
  • "hook it up to your build" -> not understood. Instructions to get it included will confuse other developers, especially when they has no my "deviations" file. – Vi. Feb 12 '10 at 02:59
  • Everything should be interfere the tracked code. It is just changes only for me in some file that is also updated by others. – Vi. Feb 12 '10 at 03:00
  • @vi so make a local_conf branch and apply it on top of your local changes for testing – Benjamin Bannier Feb 12 '10 at 03:02
  • Apply and unapply and then apply again? I forget to unapply it someday and push the "blunder wrong" change upstream. /* Oneday I actually commited "Do not commit this" commit */ – Vi. Feb 12 '10 at 03:04
  • No. For example, I was need it 1. to disable annoying Maven statistics collecting plug-in in pom.xml that required network connectivity to build successfully; 2. to remove splash screen in application we were developing; 3. add specialized logger which only I was using (and which could also break things) – Vi. Feb 12 '10 at 15:01
1

try git update-index --assume-unchanged --<path>. It acts like gitignore for files under source control. The original purpose of the feature though, was to improve performance of git checking modifications in a folder with lots of files. Here is the doco:

--assume-unchanged
--no-assume-unchanged

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. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files). You should remember that an explicit git add operation will still cause the file to be refreshed from the working tree. Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.

Igor Zevaka
  • 74,528
  • 26
  • 112
  • 128
  • Looks like it 1. Adds necessity to use custom scripts for commit/checkout. 2. Removes my ability to make useful changes in other parts of file. And what will happen if the file is updated upstream? Looks like both "filter" and "Do not commit this" variants work better. – Vi. Feb 12 '10 at 03:12
1
  • Put the canonical, default configuration in the git tree, but play no games with it. It's in the tree, and if you make changes to it, they'll be committed.
  • The software looks for the default configuration, but it also looks for a configuration in the developer's home directory. If it finds both, it merges the two. Any configuration items found in the developer's config file override those in the default config file.

Now the default config is tracked, and your customizations of the default config are not.

Wayne Conrad
  • 103,207
  • 26
  • 155
  • 191
  • All this implies that I must commit something into central repository which is not useful for other developers. These files was at all not intended to be edited by regular developers. – Vi. Feb 12 '10 at 16:08
  • Why is this file in the source repository at all? Change the software so that it looks for the config in your home directory, and if you want to version that, then create a separate .git repo for it. – Wayne Conrad Feb 12 '10 at 16:21
  • Because it was a file that tells how the project should be build (pom.xml). Not all developers knew it's details and edited them. – Vi. Feb 12 '10 at 20:22
  • Alright. I think I know what we're hung up on. Let's try something else (new answer above). – Wayne Conrad Feb 12 '10 at 21:10
0

I am not all to familiar with git. With Mercurial I use a patch queue (MQ) or the shelve (similar to git stash) for such things.

git stash can be convenient to use, if you're "localizable" information is easy to locate (e.g. all in a single config file).

Using a patch queue is a little more complex but once setup correctly superior because you can manage localizable information in a transparent push/pop manner. You can find a list of patch queues on top of git here on SO.

Community
  • 1
  • 1
Johannes Rudolph
  • 35,298
  • 14
  • 114
  • 172
  • I use "git stash" for such purpose if there are some _temporary_ changes that I don't want to commit. In my case it is _permanent_ changes that I don't want to commit. And I don't want to think about deviant files every time they got changed or when I push things. – Vi. Feb 12 '10 at 16:11