first para of man gitignore should refer to 'git rm --cached'

first para of man gitignore should refer to 'git rm --cached'

[Sitaram Chamarty]

It's an FAQ that "why doesn't my gitignore work" when the files in
question had already been added earlier, usually in error.  The most
common remedy, I believe, is "git rm --cached" followed by a commit.

"update-index" does not seem to be the right answer.

Thoughts?

-- 
Sitaram

Re: first para of man gitignore should refer to 'git rm --cached'

[Ramkumar Ramachandra]

Hi Sitaram,

Sitaram Chamarty writes:
> It's an FAQ that "why doesn't my gitignore work" when the files in
> question had already been added earlier, usually in error.  The most
> common remedy, I believe, is "git rm --cached" followed by a commit.

Er, no. The documentation says "in order to ignore uncommitted changes
in already tracked files". `git rm --cached` removes the file from the
index altogether- when the change is committed, Git will actually stop
tracking it.

> "update-index" does not seem to be the right answer.

>From the update-index documentation assume-unchanged section, "This
option can be also used as a coarse file-level mechanism to ignore
uncommitted changes in tracked files (akin to what .gitignore does for
untracked files)". It seems to be right.

-- Ram

Re: first para of man gitignore should refer to 'git rm --cached'

[Sitaram Chamarty]

On Mon, Nov 8, 2010 at 12:44 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Hi Sitaram,
>
> Sitaram Chamarty writes:
>> It's an FAQ that "why doesn't my gitignore work" when the files in
>> question had already been added earlier, usually in error.  The most
>> common remedy, I believe, is "git rm --cached" followed by a commit.
>
> Er, no. The documentation says "in order to ignore uncommitted changes
> in already tracked files". `git rm --cached` removes the file from the
> index altogether- when the change is committed, Git will actually stop
> tracking it.

I agree.

I'm just saying that ignoring uncommitted changes to already tracked
files is *not* the most common question I see when it comes to
gitignore, and am asking if it is worth putting what I believe is the
real FAQ in the first para, and move the assume-unchanged stuff
further down the page.

Sorry if I didn't say that clearly enough before.

Re: first para of man gitignore should refer to 'git rm --cached'

[Junio C Hamano]

Sitaram Chamarty <sitaramc@gmail.com> writes:

> I'm just saying that ignoring uncommitted changes to already tracked
> files is *not* the most common question I see when it comes to
> gitignore,...

I actually think it is much more commonly asked around here than "I added
paths that I do not want by mistake and I mistakenly thought adding it to
gitignore would make git forget it".

Re: first para of man gitignore should refer to 'git rm --cached'

[Sitaram Chamarty]

On Tue, Nov 9, 2010 at 1:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> I'm just saying that ignoring uncommitted changes to already tracked
>> files is *not* the most common question I see when it comes to
>> gitignore,...
>
> I actually think it is much more commonly asked around here than "I added
> paths that I do not want by mistake and I mistakenly thought adding it to
> gitignore would make git forget it".

I'm surprised.  That is something only advanced users are likely to
need, while the one I mentioned would appear to be a much more
neophyte mistake.

Perhaps it's the difference between the folks that come to #git and
those that come to the mailing list.

But case closed I guess...

Re: first para of man gitignore should refer to 'git rm --cached'

[Jonathan Nieder]

Sitaram Chamarty wrote:

> Perhaps it's the difference between the folks that come to #git and
> those that come to the mailing list.
> 
> But case closed I guess...

Case closed?  I thought you were suggesting an enhancement to the
manual page, to answer the following question (frequently asked or
not):

	If git is already tracking a file, how can I tell git
	it is not supposed to be tracked any more?

And perhaps a bonus question:

	What will happen when I switch between revisions in
	which the file is tracked and not tracked?

I think at least an EXAMPLES section explaining this would be would
be nice.