Is there a way to “freeze” a file in Git?

Question

I\'m in a situation where I want to open source my project, however there\'s a single source file that I want to release a \"clean\" version of, but use a separate version l

Answer 1

use update-index, here are the docs.

Here is a basic example freezing a file foo.rb:

git update-index --assume-unchanged foo.rb

Then, to get it back:

git update-index --no-assume-unchanged foo.rb

Or for simplicity, add it to .gitconfig

freeze = update-index --assume-unchanged
thaw = update-index --no-assume-unchanged
...
git freeze foo.rb
git thaw foo.rb

Note: This answer was originally provided by @TheAmpersand in comments above. I thought it was important enough to formalize.

Answer 2

Greg's approach very adequately and precisely answers your question.

Let me make an addition that takes into account what I infer to be your high-level objectives:

• Don't release local data to the wild
• Release a clean version into the wild

The simplest (and in my experience, best attested) way to accomplish this is to use the following structure:

Versioned

./application.code
./config.code
./config.local.code.sample
./.gitignore

application.code

include('./config.code')
if is_file('./config.local.code')
  include('./config.local.code')
end

config.code

username = 'root'
password = 'password'

config.local.code.sample

username = 'replace with your local username and rename file to config.local.code'
password = 'replace with your local password and rename file to config.local.code'

.gitignore

config.local.code

Unversioned (optionally)

./config.local.code # will not be picked up by git due to .gitignore

config.local.code

username = 'Suan'
password = 'myownpass'

Result

As you can see, you avoid releasing config.local.code, which actually contains your sensitive information, into the wild. The default configuration (cloned straight from a remote) will work for a reasonable, if rare, case where username root and a password password is valid. And the aptly named config.local.code.sample provides local customization instructions.

Answer 3

One way is to have your changes to that file in a local branch. Do your work in that branch, then rebase ignoring your changes back into the actual branch that development is happening in.

Answer 4

You can do this with Git's sparse checkout feature. Run the following commands in a repo where you want a special, untracked local.txt file:

git config core.sparsecheckout true
echo '*' >.git/info/sparse-checkout
echo '!local.txt' >>.git/info/sparse-checkout
git read-tree --reset -u HEAD

This will first delete the existing local.txt file. But now it's ignored from Git's perspective, so you can put a machine-specific one there and Git won't bother you about it.

You can then add and manage the published local.txt file from some other repository. Git will be happy to track this file and keep it in the repository, but on a machine with the above sparse checkout configuration, Git will ignore the local local.txt file in that working directory, even if it is different from what's in the repository.

Answer 5

I've solved a similar situation like this for config files in Django by using symbolic links. It seems you're looking for versioning capabilities instead of config file management, but I'm sure this little strategy could help. Here are the steps I usually take:

Say the file you want to update locally (and not to be shared) is named 'local.file' and the file that you want released (in the wild) is 'release.file'... You need to create a symbolic link file, let's call this symbolic link file 'actual.file'. The symbolic link file will either point to local.file or release.file at any given time (or be missing if you just cloned the repo).

1. gitignore local.file and actual.file so they aren't tracked since you don't want these to be kept track of or released. actual.file is always pointing to the file that you want to work with.
2. Make the symbolic link point to local.file when you're working on your 'non-frozen' version-ed file.
3. Make the symbolic link (actual.file) point to 'frozen' release.file when you want to make manual updates on it or simply copy changes from local.file to release.file.