On Sat, Jul 30, 2011 at 12:23:30PM -0400, Allan Caffee wrote: > On Sat, Jul 30, 2011 at 9:32 AM, Sverre Rabbelier <srabbelier@xxxxxxxxx> wrote: > > Does it perhaps touch some of the tracked files? That way it would > > make sense git at first thinks it's dirty (since the lstat info > > changed), but then 'git status' will actually check the contents of > > the file and notice that they're equal? Just guessing here though. > > Sounds like you're on the right track. git diff-index reveals that > the index is stale > [...] > It looks like this was caused by setuptools hardlinking files into a > temp directory and then deleting the links, as demonstrated by: Yeah, that would modify the file's ctime, which is part of what git uses to check whether its stat-cache is fresh. The problem is that we call the diff-index plumbing to determine the dirty state, but it expects the index to have been refreshed already. Describe is probably porcelain-ish enough that it should be doing the refresh for the user and writing the result out (at least if the --dirty flag is passed, as otherwise it doesn't care), just as porcelains like "diff" and "status" do. > I've tried adding a call to refresh_index() in describe.c but it > doesn't seem to have any effect on the results. (Patch below.) Any > idea what the proper fix is for this? You call refresh_index, but you never actually load the index in the first place. So nothing gets refreshed. If you add a call to read_cache just beforehand, it works as you expect. However, if describe is going to the trouble to refresh the index, it should probably actually write out the result. In that case, you would want to emulate what cmd_status does in builtin/commit.c, which writes out the new index via update_index_if_able. -Peff -- 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