1

I am working on a project which has a bit of an uncommon behaving thing:

One of the files in the source code is a file that contains serious code, but it can edit itself to also include some configuration. Whether this is good design is a different discussion, but to be able to test my project, this file needs to be in its modified state.

Before I commit anything, I normally do an A-B comparison between the situation before and after my contribution. I use git stash to switch between base and my dirty working copy. The problem is that when using git stash, it also reverts my config-thing.

My current workaround is cumbersome: I do a git add path/to/settingsfile and then git stash --keep-index, but I rather dislike this workaround. Is there a more elegant solution to have git ignore all modifications to this file unless I specify otherwise?

Pelle
  • 6,423
  • 4
  • 33
  • 50
  • 1
    You really should fix that self-editing beast , or you are not going to win this battle. – mvp Dec 11 '12 at 10:20
  • 1
    Automatically generated content should be kept in a separate, untracked file. Sorting that out will immediately solve your problems, and make everything much cleaner. – poke Dec 11 '12 at 10:22
  • Guys, I totally agree. Both +1, but note the reason that I mentioned that it's a different discussion, is that that's not supposed to be my fix, and to get it fixed, it should pass the usual bureaucracy. Eventually, if my boss / team mates want it this way or just don't care about my issue, I'm looking for an alternative. – Pelle Dec 11 '12 at 10:24

1 Answers1

1

See " Preserve git --assume-unchanged files between branch checkouts "

 git update-index --skip-worktree -- path

That wouldn't be reverted from a git stash.

Original answer

From "temporarily ignoring files ":

 git update-index --assume-unchanged <file>

That would allow to ignore changes to that specific files.
This won't help if you want to revert code changes while keeping config changes in the same file though.

And git stash will still revert it: How to prevent git stash dropping changes to files with the "assume unchanged" bit?

Note that, before Git 2.25 (Q1 2020), "git stash save" in a working tree that is sparsely checked out mistakenly removed paths that are outside the area of interest.

See commit 4a58c3d, commit 8dfb04a (30 Oct 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 57b5301, 10 Nov 2019)

stash: handle staged changes in skip-worktree files correctly

Signed-off-by: Johannes Schindelin

When calling git stash while changes were staged for files that are marked with the skip-worktree bit (e.g. files that are excluded in a sparse checkout), the files are recorded as deleted instead.

The reason is that git stash tries to construct the tree reflecting the worktree essentially by copying the index to a temporary one and then updating the files from the worktree.
Crucially, it calls git diff-index to update also those files that are in the HEAD but have been unstaged in the index.

However, when the temporary index is updated via git update-index --add --remove, skip-worktree entries mark the files as deleted by mistake.

Let's use the newly-introduced --ignore-skip-worktree-entries option of git update-index to prevent exactly this from happening.

Note that the regression test case deliberately avoids replicating the scenario described above and instead tries to recreate just the symptom.

Reported by Dan Thompson.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • It looks promising when looking at the output of `git status`, but it seems `git stash` doesn't respect that. It still reverts the file back to BASE. – Pelle Dec 11 '12 at 10:29
  • @PelletenCate yeap, I just read http://stackoverflow.com/questions/5962456/how-to-prevent-git-stash-dropping-changes-to-files-with-the-assume-unchanged-b I have updated the answer accordingly. – VonC Dec 11 '12 at 10:31
  • 1
    @PelletenCate to test: http://stackoverflow.com/a/9816844/6309 `git update-index --skip-worktree -- /path/to/file`: would `git stash` leave it alone then? – VonC Dec 11 '12 at 10:35
  • Yes, it does! :) For now, it seems to do exactly what I want it to do. Thanks a million! (Incidentally, in your answer you linked to, it seems you state that they both options get reset when the index is discarded, e.g. on a reset. Isn't discarding the index what 'stash' does as well? :) ) I'll accept your answer. Maybe you could merge the solution in. – Pelle Dec 11 '12 at 10:56
  • @PelletenCate I have updated the answer to make the solution more visible. I am guessing `git stash` doesn't exactly "reset the index" the way `git reset` does. – VonC Dec 11 '12 at 11:34