How should I indicate to git that changes are transient and shouldn't be committed?

Question

When maintaining a live system, I find that it is sometimes necessary to make ad-hoc temporary changes to files - changing logging levels, adding trace options to scripts etc.

When I do this, my semi-automated mechanisms for finding uncommitted changes and unmerged branches often show up false positives:

• If I leave changes uncommitted, or just staged, then my checker script flags up the repo as dirty.
• If I commit them as a "temporary changes commit", they get flagged up as 'changes ahead of the remote branch'
• If I commit them on a new branch without a remote, they get flagged up as a 'branch without a remote'.

Normally, all of these are needed to find changes which haven't been merged up, but this also means that every way of 'hiding' temporary changes is blocked off too.

Note that I don't want to --assume-unchanged as the same file will often contain both temporary changes (which I don't want to be reminded about) and permanent changes (which I do), and looking through Handling temporary changes (not to be committed) in Git has no suggestions which address all of these requirements.

With Mercurial, I would look into using Mercurial Queues to get somewhere close to what I want. I would create a patch with my temporary changes, then if my analysis utility found a patch queue it would pop them, perform the analysis and then push them back. This would effectively remove only the temporary changes, perform the analysis on only the changes I haven't deemed temporary, and then re-apply those changes.

The trouble with any approach which changes the working directory is that this would affect the behaviour of the live system - for instance, our logging system checks for updates to the logging configuration every 10 seconds or so.

So, how can I best indicate to git that some changes are transient and shouldn't be committed and/or merged, while others should?

Answer 1

the same file will often contain both temporary changes (which I don't want to be reminded about) and permanent changes (which I do)

• If I commit [the temporary changes] as a "temporary changes commit", they get flagged up as 'changes ahead of the remote branch'
• If I commit them on a new branch without a remote, they get flagged up as a 'branch without a remote'.

If I were doing this with mercurial I would use Mercurial Queues to put insignificant changes into a patch, and pop it before analysis, pushing it back on afterwards.

Git's your servant. You decide what commits mean. Commit your changes and use Git to distribute the hunks so they have the most useful to you commit sequence[s] and boundaries. Keep insignificant changes in an "insignificant changes" commit, or have an "insignificant changes" branch, or whatever works best. Teach your checker to identify insignificant-changes commits.

From what you've given here a single ordinary "local" branch with a tip commit dedicated to config changes should do it, when you make a "significant" change, commit and use interactive or autosquash rebase to record the change behind the tip. Tell your checker to ignore anything in the local branch's tip; to update the local config, change it and git commit --amend --no-edit it, or if you goof and commit it separately then squash it with interactive rebase or equivalently just git reset --soft @~ and do the --amend --no-edit commit you meant to do. There's no need for special facilities, you get the full toolkit for whatever work you're doing. If there are commits regarded as particularly meaningful, put them someplace reserved for commits with that particular meaning.