git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Files excluded but not ignored
@ 2013-01-30 15:34 Jason Wenger
  2013-01-30 16:17 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Jason Wenger @ 2013-01-30 15:34 UTC (permalink / raw)
  To: git

I prefer to not add core.* files to my ignore listings because I find it helpful 
to see them in git status -- It helps me notice and clean them up periodically.  
Not having them ignored is also good ,because it allows git clean to care of 
core.*  files.

The problem is that git add -A, git stash -u, etc, remain interested in the core 
files.

Trying to start up discussion of whether there would be merit to a "half-
ignored" state -- Files which are excluded from tracking, but which still 
show in git status, and which are removed by git clean.

Not trying to propose yet how .git/exclude or .gitignore would be formatted 
or anything like that.  Just looking for opinions on whether such a state 
would be considered by the community as a good thing and merit the added 
complexity in the code.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Files excluded but not ignored
  2013-01-30 15:34 Files excluded but not ignored Jason Wenger
@ 2013-01-30 16:17 ` Junio C Hamano
  2013-02-01 23:54   ` Ben Aveling
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2013-01-30 16:17 UTC (permalink / raw)
  To: Jason Wenger; +Cc: git

Jason Wenger <jcwenger@gmail.com> writes:

> I prefer to not add core.* files to my ignore listings because I find it helpful 
> to see them in git status -- It helps me notice and clean them up periodically.  
> Not having them ignored is also good ,because it allows git clean to care of 
> core.*  files.
>
> The problem is that git add -A, git stash -u, etc, remain interested in the core 
> files.
>
> Trying to start up discussion of whether there would be merit to a "half-
> ignored" state -- Files which are excluded from tracking, but which still 
> show in git status, and which are removed by git clean.
>
> Not trying to propose yet how .git/exclude or .gitignore would be formatted 
> or anything like that.  Just looking for opinions on whether such a state 
> would be considered by the community as a good thing and merit the added 
> complexity in the code.

I see no merit for "ignored and never to be tracked, but are still
shown loudly in the untracked list" myself.  Use cases for "ignored
and never to be tracked, but not expendable" class were mentioned
often in the past, though.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Files excluded but not ignored
  2013-01-30 16:17 ` Junio C Hamano
@ 2013-02-01 23:54   ` Ben Aveling
  0 siblings, 0 replies; 3+ messages in thread
From: Ben Aveling @ 2013-02-01 23:54 UTC (permalink / raw)
  To: Jason Wenger; +Cc: Junio C Hamano, git

On 31/01/2013 3:17 AM, Junio C Hamano wrote:
> Jason Wenger <jcwenger@gmail.com> writes:
>
>> Trying to start up discussion of whether there would be merit to a "half-
>> ignored" state -- Files which are excluded from tracking, but which still
>> show in git status, and which are removed by git clean.
> I see no merit for "ignored and never to be tracked, but are still
> shown loudly in the untracked list" myself.  Use cases for "ignored
> and never to be tracked, but not expendable" class were mentioned
> often in the past, though.

A new state seems over the top.

Jason, would adding a parameter to "git status" telling it to ignore all 
.gitignores give you what you need?

Regards, Ben

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-02-01 23:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-30 15:34 Files excluded but not ignored Jason Wenger
2013-01-30 16:17 ` Junio C Hamano
2013-02-01 23:54   ` Ben Aveling

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).