>>>>> "Thomas" == Thomas Rast <trast@xxxxxxxxxxx> writes: > Yann Hodique <yann.hodique@xxxxxxxxx> writes: >> I have a weird problem that seems to manifest itself only on ZFS >> (actually the Zevo distribution, on OSX). With git 1.8.2.1 by the way. >> I just switched to ZFS, so I can't blame that particular version of git. >> >> "Sometimes" (I'd say something like 10-15% of the time, fairly >> reproducible anyway), "git diff-files" will see changes that don't exist >> for some time, then will catch up with the actual state of the file: >> >> $ git checkout next; git diff-files; git checkout next; git diff-files >> Already on 'next' >> :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80 0000000000000000000000000000000000000000 M magit.el >> Already on 'next' >> $ > git-diff-files doesn't refresh the index. Why are you using it? It's > the plumbing version of 'git diff' (without args), which does the same > but *does* refresh the index. Well, as I said, I'm mostly trying to minimize the case here (which might or might not be successful, as it's essentially guesswork). But whatever git-diff-files does, it seems odd that it doesn't report the same thing twice, no ? The actual real problem I have is the one that's exposed in the longer trace I posted: git merge kindly asks me to fix a problem that a) doesn't exist and b) isn't reported by porcelain commands (git diff, and git status), and then magically stops asking after a couple of seconds. Thanks, Yann. -- Battle? There's always a desire for breathing space motivating it somewhere. -- The Bashar Teg -- 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