Ok, I've made a bugzilla entry for this for the Fedora people, but I thought I'd mention something I noticed yesterday but only tracked down today: it seems like the beagle file indexing code is able to screw up git in subtle ways. I do not know exactly what happens, but the symptoms are random (and quite hard-to-trigger) dirty index contents where git believes that some set of files are not clean in the index. I *suspect* that beagle is playing games with the file access times, causing the ctime on disk to not match the ce_ctime in the index file. But that's just a guess. I'm posting here in case somebody on the list knows what beagle does, or somebody has been bitten by strange behaviour and realizes that he has beagle running and prefers to fix the problem by just disabling beagle (which will also be a great boon for performance - beagle seems to be very good at flushing your file caches, but I guess that's not a bug, but a "feature"). The easiest way I have found so far to trigger this is to run while ./t7003-filter-branch.sh -i; do echo ok; done in the git t/ directory, while at the same time telling beagle to index just that git/t/ directory. That seems to trigger a failure on subtest 17 fairly reliably (not the first time through the loop, but *eventually* - it takes a few minutes). I think it's because "git filter-branch" requires the index to be clean. (But I've also seen it fail on subtest 4). I opened bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=380791 for this, since I consider it a beagle bug (indexing shouldn't change directory state, and if beagle wants to avoid changing access times, it should use O_NOATIME). But I don't actually know exactly what it is that causes problems, so if somebody is interested and tries to figure this out, that would probably be good. Linus - 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
