Re: consistency problem on ZFS

From: Yann Hodique <yann.hodique@gmail.com>
Date: Apr 28, 2013, 19:44 UTC
Message-ID: <m261z6xwwl.fsf@jarvis.hodique.info>
In-Reply-To: <87k3nme9ha.fsf@hexa.v.cablecom.net>

>>>>> "Thomas" == Thomas Rast <trast@inf.ethz.ch> writes:

Show 14 quoted lines

> Yann Hodique <yann.hodique@gmail.com> 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