On Tue, Aug 09, 2016 at 11:33:37AM +0000, Torsten Bögershausen wrote: > > The second one seems plausible, given the history of issues with > > changing CRLF settings for an existing checkout. I'm not sure if it > > would be feasible to reset the index completely before each tested > > command, but that would probably solve it. > The content of the file has been changed (we appended the letter 'Z' to it, > so even if mtime is the same, st.st_size should differ. > And it seems as if the commit is triggered, see below. I don't think I made myself clear. It's not a question of whether there is something to commit. It's that when git asks the index "what is the sha1 of the content at this path?", the index may be able to answer directly (the file is up-to-date, so we return the index value), or it may have to go to the filesystem and read the file content. It is this latter which triggers convert_to_git(), which is what generates the message in question. For a more stripped-down example, try: git add foo git commit -m msg versus: git add foo sleep 1 git commit -m msg In the latter case, we should not generally need convert_to_git() in the "commit" step. It was already done by "git add", and we reuse the cached result. Whereas in the first one, we may run into the racy-index problem and have to re-read the file to be on the safe side. -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