On 6/27/08, Jakub Narebski <jnareb@gmail.com> wrote:
quoted text
> "Avery Pennarun" <apenwarr@gmail.com> writes:
> > On 6/26/08, Stephen R. van den Berg <srb@cuci.nl> wrote:
>  >> Avery Pennarun wrote:
>  >>> 1) What's a sensible way to tell git to *not* opendir() specific
>  >>> directories to look for unexpected files in "git status"?  (I don't
>  >>> think I know enough to implement this myself.)
>  >>
>  >> Would checking the mtime on the directory itself help?
>  >
>  > I'm guessing it would help somewhat (although not as much as not
>  > checking anything at all).  However, we'd still have to check the
>  > mtime *against* something, and I don't think the index stores
>  > information about directories themselves.
>
> By the way, from time to time there on this mailing list is idea
>  to add entries for directories in the index.  This could help situation
>  like yours, tracking emty directories, faster operations when some trees
>  are unchanged, subtree <-> subproject changes.
>
>  But it always comes back to: 1.) no proposed implementation, 2.) "git
>  tracks contents"...

Yes, I've seen the occasional discussions about this.

I might volunteer to help solve (1) except that I have a feeling that
changing the index format would mangle all sorts of things beyond my
current understanding.  Attaining that understanding might not be so
bad, except for (2), which seems like any proposed changes will
probably be rejected anyhow.

So naturally I was hoping for a magical alternative suggestion for my
current problem instead :)  One option I'm thinking about is to have
my proposed daemon keep its own "index", which tracks *all* the files
on the filesystem, not just the ones that have been
git-update-index'd.  Then anything that needs to compare against the
filesystem can choose to compare against the contents of this file
instead if it exists (and/or the right option is set, etc).  Does that
sound sane?

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html