Andreas Ericsson venit, vidit, dixit 10.06.2010 10:03:
> On 06/09/2010 10:21 PM, Michael J Gruber wrote:
>> Heya,
>>
>> now what is going on here? After upgrading to current next I get
>>
>> warning: working tree spans across filesystems but
>> GIT_DISCOVERY_ACROSS_FILESYSTEM is not set.
>>
>> in several repos, such as my local git.git repo. That is certainly on a
>> single file system only (ext4 over lvm over luks, all on one partition,
>> Fedora 13). I also get this for another repo, but not for every repo. It
>> goes away when I set the var and comes back when I don't set it, of course.
>>
>> Although I haven't bisected this should be due to
>> 52b98a7 (write-index: check and warn when worktree crosses a filesystem
>> boundary, 2010-04-04).
>>
>> How does the code detect a file system boundary, and where could it go
>> wrong?
>>
>
> According to the patch, it checks if the device id recorded from stat(2)
> is the same for all files and, if not, warns about it.
>
> It seems that your interpretation of "one partition" differs from that
> reported by the kernel. Why that is so, I have no idea.
>
I'm sorry, but "my interpretation"? WTF? This is all on
/home/mjg/src/git which has no bind mounts whatsoever.
I actually mixed up my / and /home situation above, /home is even
simpler: single ext3 over luks dm device over single "real" partition.
All of this (except for single ext3 part.) should not matter, of course.
I bisected it just be sure, and it boils down to 9780e62 which is the
commit merging 52b98a7 to next.
git ls-files|xargs stat -c "%d %D" |sort|uniq
gives
64772 fd04
which is, in particular, 1 device only. Now, here comes funny. After
changing write_index() to print the two ce_dev's which differ, i.e.
printf("%d %d\n", ce->ce_dev, cache[first_valid_ent]->ce_dev);
I have:
./git-status -s|sort|uniq -c
warning: working tree spans across filesystems but
GIT_DISCOVERY_ACROSS_FILESYSTEM is not set.
150 64770 64772
662 64771 64772
1 M read-cache.c
WTF???
git reset --hard doesn't help this.
rm .git/index && git reset does help.
So, it seems that nowadays not even "reset --hard" refreshes the index
completely. After a reboot your device IDs may change, of course, and
files on the same file system will have different ce_dev values in the
index depending on when their index entry was refreshed last.
I really don't know how to fix this (other than by refreshing stat info
in write_index() before warning). Debugging it was quite an exercise
already.
Also, having git reset --index do the equivalent of "rm .git/index &&
git reset" might be good to have.
I'm keeping the bad index, btw, so that I can test a possible future fix.
Michael
--
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