All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: kusmabite@gmail.com
Cc: Erik Faye-Lund <kusmabite@googlemail.com>,
	Andreas Ericsson <ae@op5.se>,
	Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: Misterious warning about file system boundaries [It's a bug, not a mystery.]
Date: Thu, 10 Jun 2010 12:36:30 +0200	[thread overview]
Message-ID: <4C10C02E.50502@drmicha.warpmail.net> (raw)
In-Reply-To: <AANLkTimwhDGNTMiOaW8_AGGd4PvFtyILEikePdC4zGDo@mail.gmail.com>

Erik Faye-Lund venit, vidit, dixit 10.06.2010 11:39:
> On Thu, Jun 10, 2010 at 11:05 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> 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.
>>
> <snip>
>>
>> Also, having git reset --index do the equivalent of "rm .git/index &&
>> git reset" might be good to have.
>>
> 
> Doesn't "git update-index --refresh" do the trick?
> 

No.

And neither does --really-refresh.

I guess we need --I-really-mean-it-refresh.

In fact, not even after recompiling with USE_STDEV=y that
--really-refresh helps which stomps me.But what do I know.

Michael

  reply	other threads:[~2010-06-10 10:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 20:21 Misterious warning about file system boundaries Michael J Gruber
2010-06-10  8:03 ` Andreas Ericsson
2010-06-10  9:05   ` Misterious warning about file system boundaries [It's a bug, not a mystery.] Michael J Gruber
2010-06-10  9:39     ` Erik Faye-Lund
2010-06-10 10:36       ` Michael J Gruber [this message]
2010-06-10 10:52         ` Ævar Arnfjörð Bjarmason
2010-06-10 11:02           ` Jeff King
2010-06-10 14:53             ` Junio C Hamano
2010-06-12  4:24               ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C10C02E.50502@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kusmabite@gmail.com \
    --cc=kusmabite@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.