8

A lot of times, I like to modify some lines of code in order to make debugging easier, but I don't actually want to commit them. For instance, I'll disable some annoying features (like ads) by commenting out some lines of code, or I'll set the log levels and filters to only the ones I care about, or I'll force a conditional to be true just so the block of code I want to run actually runs all the time.

In Perforce, I would have created a "changelist" for these files and labeled it as "DON'T COMMIT!". What would be the equivalent of this in Git? A branch doesn't work because these debug-only modifications need to exist with other changes I'm currently making.

thien
  • 406
  • 2
  • 11

5 Answers5

5

Lookup the --assume-unchanged option. There is a blog article about this which explains things quite well. And also this one which mentions finding such ignored files later on.

patthoyts
  • 32,320
  • 3
  • 62
  • 93
3

Thanks all for the answers. What I ended up doing is writing a pre-commit hook in git that checks for the string "dont commit" (and other variations) in each of the files. If it does, then the commit fails, and I'll have to edit those lines before committing. This is because debug code should be treated on a per-line basis, not per-file, because some files have both debug changes and real changes to be committed. (my old solution with perforce did not address this issue).

thien
  • 406
  • 2
  • 11
1

What I usually do is just put the debug code in its own commit and revert that commit later. A more involved solution is to make an intermediate branch off of master, call it debug. Make all your debug changes in the debug branch, then make your feature branch off of debug. When you're ready to remove the debug changes, just rebase your feature branch onto master.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
0

You actually do not want to ignore those files, but ignore those changes.

I see two solutions here:

  1. Restore HEAD

The command I'm using for such situation is:

git checkout -- file ...

With all the files you modified for debugging purpose.

This restores the file as of HEAD. Then you can safely make your git commit -a or whatever.

  1. Tell git to ask you what changes to commit (per file)

    git add -p .

See #1085162.

But you will still need to remove your debugging code.

Community
  • 1
  • 1
shkschneider
  • 17,833
  • 13
  • 59
  • 112
0

One of solutions that's not universal but may fit to some workflow scenarios is to apply Git's pre-commit filters (manual, manual + samples). In brief, it's just a preprocessing tool that would be called over all committed files before actual commit. You could have this mechanism to strip out certain patterns like //<NOCOMMIT ... //NOCOMMIT> or whatever you like. Drawback is that these debug lines may disappear when resetting to a commit or even pulling/merging (I didn't check that).

Fr0sT
  • 2,959
  • 2
  • 25
  • 18