On 6/27/08, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > "Avery Pennarun" <apenwarr@xxxxxxxxx> writes: > > On 6/26/08, Stephen R. van den Berg <srb@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
