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

> Yann Hodique <yann.hodi...@gmail.com> writes:
>> I have a weird problem that seems to manifest itself only on ZFS
>> (actually the Zevo distribution, on OSX). With git 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.



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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to