Re: git pull not ignoring the file which has been sent to the temporary ignore list

Stefan Beller [off-list ref] writes:

quoted

Ok. How should I then ignore any local changes to the .gitignore
file ? And while taking pull, git should skip this file ?

Look at .git/info/exclude

Good answer for ".gitignore".  In general, you do not "ignore local
changes" to tracked paths.

I found https://help.github.com/articles/ignoring-files/ as Googles
first hit, which advises to use
    git update-index --assume-unchanged path/to/file.txt
Not sure if that is most helpful advice there.

The piece of advice in the last paragraph on that page is wrong (and
it has been wrong from the day it was written).

The gitignore(5) documentation used to have a similar incorrect
piece of advice but we finally corrected it recently.

Cf. http://thread.gmane.org/gmane.comp.version-control.git/260954/focus=261118

On Fri, Jan 23, 2015 at 1:14 PM, Junio C Hamano [off-list ref] wrote:

Good answer for ".gitignore".  In general, you do not "ignore local
changes" to tracked paths.

I assumed Arup would want to ignore more than is in the upstream project,
so you'd come up with an appendix to the .gitignore file because that file
is rather obvious to find (it's printed when git pull modifies it,
'ls' just find it,
you'd not look into .git/info/exclude by chance)

Assuming you want to ignore less than the upstream project (delete some
lines from .gitignore) it get's tricky in my opinion. Either have a local commit
and just use 'git pull' to resolve the conflicts with upstream. The problem then
arises if you want to publish your changes (such as pushing your changes and
creating a pull request, then you have that commit included, which you maybe
don't want to include)

Mind, that I am talking about possible work flows to circumvent an
assumed problem
which would result in problems as described in the first mail.

On Friday, January 23, 2015 01:14:03 PM you wrote:

Stefan Beller [off-list ref] writes:

quoted

quoted

Ok. How should I then ignore any local changes to the .gitignore
file ? And while taking pull, git should skip this file ?

Look at .git/info/exclude

Good answer for ".gitignore".  In general, you do not "ignore local
changes" to tracked paths.

There are some configuration files, like `database.yml`, where we generally put our local DB credentials and we don't want to share such things. That's why we always put related settings inside the .gitignore file. But  while I will change it, git will not track the changes of the file, but .gitignore. That's why I used the first thread command. But when the time the came to take a `git pull`, I got to know about the mess. What should be the ideal decision in this case ?

quoted

I found https://help.github.com/articles/ignoring-files/ as Googles
first hit, which advises to use
    git update-index --assume-unchanged path/to/file.txt
Not sure if that is most helpful advice there.

Yes, I followed the same.

The piece of advice in the last paragraph on that page is wrong (and
it has been wrong from the day it was written).

The gitignore(5) documentation used to have a similar incorrect
piece of advice but we finally corrected it recently.

Cf. http://thread.gmane.org/gmane.comp.version-control.git/260954/focus=261118

-- 
================
Regards,
Arup Rakshit
================
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

--Brian Kernighan

On Sat, Jan 24, 2015 at 10:20:46AM +0630, Arup Rakshit wrote:

On Friday, January 23, 2015 01:14:03 PM you wrote:

[..]

There are some configuration files, like `database.yml`, where we
generally put our local DB credentials and we don't want to share such
things. That's why we always put related settings inside the
.gitignore file. But  while I will change it, git will not track the
changes of the file, but .gitignore. That's why I used the first
thread command. But when the time the came to take a `git pull`, I got
to know about the mess. What should be the ideal decision in this case
?

In an ideal sittuation, configuration data is not stored inside git,
because this would tie the code only to one environment.

So what you would store in git is a template of the configuration data,
that can be used to create the actual config file that is used.

This way, you don't have any problems with having to change tracked
files only for you local environment.