What is a practical workflow for keeping local changes uncommitted in git?

Question

What I want to do is already described in that question. But I want to solve that problem in a practical and more generic way. So the use-case is the following:

• I have several local changes in several files web.config, createDb.sql or in any others
• I don't want to commit those files, since changes are specific to my local machine only
• Those files must be version controlled and moreover changes are made pretty often to some of them (sql scripts in particular), so I want to receive updates for those files
• I do want to commit all other files
• I want to be able to do that without friction, in one command (using posh-git, so powershell is welcome)

The linked-to solution said to use git add -p and that is not practical, it is boring to pick chunks manually all the time or maybe there is a more convenient way of doing that?

For instance, one of the following could work:

• if there is an ability to filter files that are in my working copy before adding them to index, something like git -add -A -EXCEPT web.config crateDb.sql. Then I can map a git alias to that and that's it.
• if there is an ability to de-apply stash. I mean to remove changes that is contained in one specific stash from the working copy. So I will have to do something like git stash -deapply before each commit that is also fine.

The problem is very common and it is weird that there is no solution currently. E.g. TortoiseSVN has "ignore-on-commit" feature, Perforce allows to store that type of local changes in a separate changelist and never submit it.

Answer 1

You could try doing the following before your git commit:

git update-index --assume-unchanged web.config crateDb.sql

From git help:

--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). 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.