Can a file be marked as excluded from future commits?

user_1762276 0
Viewed 53

I have a template file which I've added to my git repository. I'm now making changes to the file for testing but these changes should remain in my working tree and never committed.

I tried adding the file to the exclude list but this has no effect; changes are still visible during an attempt to commit and I have to ignore the file manually every time.

I understand that this is because the file has a history and excluding it would be ambiguous: should it be excluded from reverting to earlier in history, etc.

My question is whether there is a way to mark a file so that I don't accidentally commit it and push it out to a remote repository like github when it's only meant for local testing.

git
4 Answers

My question is whether there is a way to mark a file so that I don't accidentally commit it and push it out to a remote repository like github when it's only meant for local testing.

There is no way to prevent yourself from saying add myFile except to use your brain and not say it.

If the question is how to prevent add . from including myFile, the answer is, put myFile in the gitignore list and git rm --cached myFile to get it out of the index.

user_3419940

As Matt suggested you can add the file to your gitignore so the changes to won't be tracked. But I'm assuming you do want to keep to file in your repository after your tests. So you'd have to remove the file from gitignore after you're done testing.

So you'd have to either remember not to accidentally commit the change to the file, or remember to remove it from gitignore.

user_34115560

Git does have two flag bits you can set in the index. Neither one is meant for what you are doing, but both work for what you are doing, provided you remember various caveats.

The two flags are "assume unchanged" and "skip worktree". The former is meant for systems on which lstat system calls are very slow, and the latter is meant for sparse checkout. If you use either of these intended-uses, the attempt to set the bit for an unintended use could interfere with that.

To set the bits, use git update-index. To remove the setting of the bits, use git update-index. The flags to git update-index are:

  • --assume-unchanged, --no-assume-unchanged: sets or clears the assume-unchanged bit
  • --skip-worktree, --no-skip-worktree: sets or clears the skip-worktree bit

You must also provide the names of the index entries on which you wish to set or clear these bits.

Once either bit is set, Git stops actually checking the working tree copy, so that git add -u, git add ., and the like don't actually add the file: the copy that's already in the index, remains in the index, unchanged. In fact, git add with the file explicitly named usually doesn't update the file in the index either.

It's probably better not to set the flag, and just manually git restore --source=HEAD --staged myFile before committing, if you've accidentally staged an updated version. Note that you can abbreviate this to git restore --staged myFile or git restore -S myFile.

user_12564520

You can create a separate branch for testing:

git checkout -b test_branch_name

user_129032470
Related