Hi Nevada,
Nevada Sanchez wrote:
> # Commit a file that will end up in .gitignore
> echo 'original settings' > mine.conf
> git add mine.conf
> git commit -m "Unknowingly committed my settings."
>
> echo '*.conf' > .gitignore
> git add .gitignore
> git commit -m "Users shouldn't commit their settings"
Naming a file in .gitignore tells git that you do not want to track it
and are giving git permission to write over it. This commonly happens
when people check in build products. For example:
git rm -f my-build-product
echo /my-build-product >>.gitignore
git commit -m "Remove generated my-build-product file"
make my-build-product
git checkout HEAD^
Without that rule, this 'git checkout' command would fail.
That said, there are some cases (e.g. the .conf file case you mention)
where a person would want git not to track a file but do not want to
give git permission to write over it. As you've seen, .gitignore does
not work well for this. :/
Ideas for next steps:
1. The gitignore(5) manpage does not do a good job of emphasizing
that files named there are not precious and can be overwritten by
git. Do you have ideas for wording that would help with that?
This would be especially welcome if you can phrase them in the
form of a patch against Documentation/gitignore.txt.
2. Occasionally people have mentioned the idea of a .gitprecious file
listing precious files that git should not track and not overwrite
(e.g., keys and other configuration files, IDE state, or metadata
for another version control system being used in parallel). Would
you be interested in working on that?
Thanks and hope that helps,
Jonathan