git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: git-status and git-diff now very slow in project with a submodule
Date: Thu, 20 May 2010 18:17:04 +0100	[thread overview]
Message-ID: <201005201817.05593.andyparkins@gmail.com> (raw)
In-Reply-To: <7vy6fe7ldo.fsf@alter.siamese.dyndns.org>

On Thursday 20 May 2010 14:28:35 Junio C Hamano wrote:

> > One additional small point: why do untracked files in a submodule make
> > the module dirty?  I've often got a few "temp.ps" or "debug.log" or
> > "backtrace.log" files lying around -- inappropriate to add to an
> > ignore file, but they don't make my working directory dirty.
> 
> "They don't make my working directory dirty" is something only you can
> decide, until you tell git about that fact, isn't it?

Perhaps I've misunderstood then; I have always understood that "dirty" was 
the name we give to the state when tracked files have changes in the working 
directory.  If not, then what word should be used to distinguish between 
tracked files unchecked in and untracked files?

Anyhoo; I don't mind.  Me starting a semantics debate isn't helpful is it?

> The way to tell git about them is to use the ignore/exclude mechanism.
> Why are they "inappropriate to add to an ignore file"?  At least you
> could have "*.log" in your personal exclude $GIT_DIR/info/exclude, no?

I think you've taken me too literally; I was trying to get across the idea 
that they are files that are made on the fly, and when I notice them they 
just get deleted.

Also, I don't want *.log, or *.ps -- neither of them is guaranteed to be an 
ignore pattern.  These throw away files have all sorts of names, made up on 
the spot as I'm working, adding them to an ignore file is overkill from my 
point of view.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

  reply	other threads:[~2010-05-20 17:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-20 10:01 git-status and git-diff now very slow in project with a submodule Andy Parkins
2010-05-20 10:10 ` Stefan Naewe
2010-05-20 11:37   ` Andy Parkins
2010-05-20 15:52     ` Michael J Gruber
2010-05-20 17:45       ` Andy Parkins
2010-05-20 17:49         ` Jens Lehmann
2010-05-20 18:01           ` Andy Parkins
2010-05-21 12:36             ` Nguyen Thai Ngoc Duy
2010-05-20 13:28 ` Junio C Hamano
2010-05-20 17:17   ` Andy Parkins [this message]
2010-05-20 22:59     ` Junio C Hamano
2010-05-21 12:05       ` Jens Lehmann
2010-05-21 12:52   ` Leo Razoumov
2010-05-21 17:54     ` Andreas Schwab
2010-05-22 12:05       ` Jens Lehmann
2010-05-22 12:08     ` Jens Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201005201817.05593.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).