Re: Bug with .gitignore and branch switching

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 17, 2017, 21:54 UTC
Message-ID: <20170317215442.GN26789@aiede.mtv.corp.google.com>
In-Reply-To: <CAPUVn2u0Uos2mT5+4ejj8m0okNK6XwerL6ce2miHfhtuEs-ZnQ@mail.gmail.com>

Hi Nevada,

Nevada Sanchez wrote:

Show 8 quoted lines

> # 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