Glenn Griffin wrote: > On Thu, Nov 20, 2008 at 4:28 PM, Jean-Luc Herren <jlh@xxxxxx> wrote: >> The first 'git status' shows the same difference as the second, >> just the second time it's staged instead of unstaged. Why does it >> take 16 seconds the second time when it's instant the first time? > > I believe the two runs of git status need to do very different things. > When run the first time, git knows the files in your working > directory are not in the index so it can easily say those files are > 'Changed but not updated' just from their existence. I might be mistaken about how the index works, but those paths *are* in the index at that time. They just have the old content, i.e. the same content as in HEAD. When HEAD == index, then nothing is staged. But the presence of those files alone doesn't tell you that they have changed. You have to look at the content and compare it to the index (== HEAD in this situation) to see whether they have changed or not and for some reason git can do this very quickly. > The second run > those files do exist in both the index and the working directory, so > git status first shows the files that are 'Changes to be committed' > and that should be fast, but additionally git status will check to see > if those files in your working directory have changed since you added > them to the index. Which is basically the same comparision as above, just it turns out that they have not changed. But even then, we're talking about comparing a 1 byte file in the index to a 1 byte file in the work tree. That doesn't take 16 seconds, even for 100 files. So this makes me believe it's the first step (comparing HEAD to the index to show staged changes) that is slow. And when you compare a 1MB file to a 1 byte file, you don't need to read all of the big file, you can tell they're not the same right after the first byte. (Even an doing stat() is enough, since the size is not the same.) Another thing that came to my mind is maybe rename detection kicks in, even though no path vanished and none is new. I believe rename detection doesn't happen for unstaged changes, which might explain the difference in speed. btw, I forgot to mention that I get this with branches maint, master, next and pu. (And I hope you don't mind I take this back to the list.) jlh -- 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
