Linus Torvalds <torvalds@xxxxxxxx> writes: > The way I found this also showed a potential performance problem: if you > do a "git reset --hard" (or similar) after you have changes in your tree, > it will write the index file with the same timestamp as the checked out > files that it re-wrote. >... > We should really try to have some way to re-generate the index > automatically when this case triggers, so that we only need to do it > _once_ rather than keep doing it forever while the index is "potentially > stale". > > Any ideas? Just before writing the index out, we could do a gettimeofday() and wait for 1 second (or two if you are on FAT) if we have many many paths that have the same timestamp. Ugly and would not work on NFS I suspect. We could do gratuitous "update-index --refresh" but that is uglier especially if done at the core level; the caller does not expect the index file to be updated. Or we could remove the check and tell the user not to touch the working tree after calling update-index (I am not seriously suggesting this). - : 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