Git: don't update certain files on Windows

Question

We work with a git respository that has over 20,000 files.

My group maintains local versions of about 100 or so of configuration and source files from this repository. THe original acts as a sort of base that several groups modify and tweak to their own needs (some core things are not allowed to be changed, but front end and some custom DB stuff are different between groups)

So we want to update to the latest version generally, but not have the git update overwrite the files that we keep local modifications for.

The machines we use are windows based. Currently the repository gets cloned to a windows server that then gets checked out/cloned to the development machines (which are also windows). The developers make changes as necessary and recommit to our local repo. The local repo updates against the master daily. We never commit back to the master.

So we want all the files that haven't been changed by our group to update, but any that have been changed (ever) won't get updated.

Is there a way to allow this to happen automatically, so the windows server just automatically updates daily, ignoring those files we keep modifications for. And if we want to add a new file to this "don't update" list its just a right-click (or even a flat file list away). I looked at git-ignore but it seems to be for committing, not for updating.

Even better would be a way to automatically download the vanilla files but have them renamed automatically. For example settings.conf is a file we want to keep changes on generally, but if they modify the way entries in that file are handled or add extra options it would be nice it it downloaded it as settings.conf.vanilla or something so we just run a diff on .vanilla files against ours and see what we want to keep. Though this feature is not absolutely necessary and seems unlikely.

If this cannot be accomplished on a windows machine (the software for windows doesn't support such features), please list some Linux options as well if available. We do have an option to use a Linux server for hosting the local git repo if needed.

Thanks.

Answer 1

It sounds like you're working with a third party code base that's under active development and you have your own customisations which you need to apply.

I think the answer you're looking for is rebase . You shouldn't need to write any external logic to achieve this, except for a job which regularly pulls in the third party changes and rebases your modifications on top of them.

This should also be more correct than simply ignoring the files you've modified, as you won't then accidentally ignore changes that the third party has made to those files (you may sometimes get a conflict, which could be frustrating, but better than silently missing an important change).

Assuming that your local repo is indeed simply a fork, maintain your changes on your own branch, and every time you update the remote repository, simply rebase your local branch on top of those changes:

git pull origin master
git checkout custom_branch
git rebase master

Edit

After you've done this, you'll end up with all the changes you made on your custom_branch sitting on top of master . You can then continue to make your customisations on your own branch, and development of the third party code can continue independently.

The next time you want to pull in the extra changes, you'll repeat the process:

Make sure you're on the master branch before pulling in changes to the third party code:

git checkout master

Pull in the changes:

git pull origin master

Change to your customised branch:

git checkout custom_branch

Move your changes on top of the third party changes:

git rebase master

This will then put all your own changes on top of master again. master itself won't be changed.

Remember that the structure of your repo just comes from a whole set of "hashes" which form a tree. Your branches are just like "post it" notes which are attached to a particular hash, and can be moved to another hash as your branch grows.

The rebase is like chopping off a branch and re-attaching it somewhere else. In this case, you're saying something like "chop off our changes and re-attach them on top of the main trunk".

If you can install a visual tool like GitX, it will really help to see how the branch tags move around when you rebase. The command line is ideal for working with but I find something like GitX is invaluable for getting a handle on the structure of your repo.