Hi, my company started recently to use Git for source version control, and due to the incompetence of the coders - that's me and my boss :-P - we have a really nice spaghetti of files being overwritten here and there.
Is there a way to mark certain files as 'untouchable' so if when updating a branch from another either do(es)n't overwrite the file(s) or doesn't do the update at all?
Thanks in advance.
views:
420answers:
5In general, Git tries to avoid overwriting changed files when using checkout to move from branch to branch. That is, if a file has not been changed and Git needs to change it, the file will change (the previous file contents still exists in the previous branch). If the file has been changed and Git does not need to change it, the file contents will be preserved. If the file has been changed and Git wants to change it, you will be notified that the local changes conflict with the branch change and Git will refuse to switch branches.
In order to understand why your files were unexpectedly overwritten, we'll probably need more information about what you did.
Sounds like what you want is to stop git from tracking the 'untouchable' files. This is done by using the git rm command.
git rm <file>
If that is what you want, use at the --dry-run switch to preview what will happen. If you're sure you want remove the files, you may want to use the --cached switch so the local files aren't removed.
Of course, you'll have to manually add the files to future branches which is probably not a good idea.
It takes very specific actions to get Git to throw away information and even then it doesn't overwrite information. So the situation may not be what you think it is.
Think of a Git repo as a transactional database of your source code. Depending on your os and setup, it may be a hidden database, so that all you see is the working directory.
The thing is: Git uses that working directory in your local file system as a browser on the database. That 'view' can change and the record of all your transactions (commits) is still in the repo, unchanged.
So the working directory that you see will change according to what 'view' (checkout, usually a branch) you have invoked. Even the file copies that are open in your text editor can change, which really weirded me out the first time I noticed it.
You can throw away prior work, for example:
1. git reset HEAD~2
which throws away you last two commits or
2. checkout -f
which throws away uncommited changes in your working directory (irretrievably if they haven't been git add
ed) before changing to a different branch ('view')
but you can't inadvertantly overwrite info without at least getting a warning message. In most cases, the info is still in the repo until it is garbage-collected, usually after more than 30 days.
As Greg said, we will need more info to know for sure.
You can add a file named .gitignore. Any filename that matches a regular expression in that file will be ignored by git.
So, I usually start with something like:
*.log
*~
conf/*
Modify to taste.
You can do exactly what you're asking for with hooks, but I don't know if that solves your real problem.
If it's as simple as your in-progress files getting munged, that's easy: Never pull/merge/rebase with uncommitted changes. Always commit before bringing in any other code.