Steffen Prohaska <prohaska@xxxxxx> writes: >> Wait a minute. >> >> What does the above "After a 'git merge'" exactly mean? After a >> successful automerge that made a commit, of stopped in the >> middle because of conflicts? I am getting an impression that >> Steffen is talking about the former, but if that is the case, >> somebody is seriously confused. > > Yes. I'm talking about a successful merge that made a commit. > >> When "merge-recursive" with a 3-way file level merge in core >> writes the result out to the work tree, it uses a cache entry >> that is stat clean (see merge-recursive.c::make_cache_entry(), >> refresh option is passed and it calls refresh_cache_entry() to >> obtain the cached stat bits). The traditional "read-tree -m -u" >> followed by merge-one-file of course runs "git update-index" >> inside merge-one-file script and cleanly merged paths should be >> stat clean after a merge. > > Well, they are not with msysgit. At least not all, or not always. > I'm not completely sure about the details, but the problem > happens frequently, near to always. Johannes, is this something you want me to look at? I do not know how much read-cache.c and other low level routines of Windows version deviated from the mainline. I do not think we touched this area in any major way recently, but I wouldn't be surprised if refresh_cache_entry() around lstat() on the Windows side looked drastically from the POSIX version. - 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
