How I can store some local changes that survives git reset --hard

Question

I have some local changes (not in separate files so .gitignore doesn't work) that I don't want to commit.
I do git reset --hard sometimes after commit to clear occasional changes but obiously I also lose my useful changes that I want to leave.

How I can keep my useful changes?

score 6 · Answer 1 · answered Jun 02 '13 at 10:25

6

You can use git stash to store your changes temporarily, then pull them back later - see the Pro Git chapter on stashing.

answered Jun 02 '13 at 10:25

Paul Dixon

295,876
54
310
348

Yes I know about ```git stash``` but I don't want to stash my changes every time. – freemanoid Jun 02 '13 at 10:43
6

@freemanoid, okay, let's pretend your imaginary `git preserve-these-and-these-changes` command do exist; then each time you'd want to preserve something to survive `git reset --hard` you'd need to call that imaginary command and then call yet another command to "undo" that preservation status it set on selected files. Now how this would be different from `git stash` / `git stash pop`? – kostix Jun 02 '13 at 13:43

score 5 · Accepted Answer · edited May 23 '17 at 12:04

You can also try:

git update-index --skip-worktree -- file
# to cancel it:
git update-index --no-skip-worktree -- file

It should resist a git reset --hard. (see this answer on the '--' double hyphen use)
See this blog post.

It looks like skip-worktree is trying very hard to preserve your local data. But it doesn’t prevent you to get upstream changes if it is safe. Plus git doesn’t reset the flag on pull. But ignoring the ‘reset --hard' command could become a nasty surprise for a developer.

assume-unchanged flag could be lost on the pull operation and the local changes inside such files doesn’t seem to be important to git.
Assume-unchanged assumes that a developer shouldn’t change a file. If a file was changed – than that change is not important. This flag is meant for improving performance for not-changing folders like SDKs. But if the promise is broken and a file is actually changed, git reverts the flag to reflect the reality. Probably it’s ok to have some inconsistent flags in generally not-meant-to-be-changed folders.

On the other hand, skip-worktree is useful when you instruct git not to touch a specific file ever. That is useful for an already tracked config file. Upstream main repository hosts some production-ready config but you would like to change some settings in the config to be able to do some local testing. And you don’t want to accidentally check the changes in such file to affect the production config. In that case skip-worktree makes perfect scene.

@freemanoid simply `git update-index --no-skip-worktree -- aFile` — VonC, Jun 02 '13 at 19:25
Hmm I did not find this while looking through man but it was there. So ```git update-index --no-skip-worktree my_file``` works. — freemanoid, Jun 02 '13 at 21:21
@freemanoid Excellent. I have added that command in the answer for more visibility. — VonC, Jun 02 '13 at 21:25

score 0 · Answer 3 · answered Jun 02 '13 at 13:05

If you never want these changes to be committed but always need them locally then consider creating and commiting a script or patch file for your local changes. Then you can keep and document your changes as well as easily apply them after a hard reset.

If you have changes that are specific to your environment then it may be worth externalising them into a configuration file.

How I can store some local changes that survives git reset --hard

3 Answers3

Linked