On 01/29/2013 11:09 AM, Mark Salter wrote:
> On Tue, 2013-01-29 at 14:12 +0800, Chen Baozi wrote:
>> On Tue, Jan 29, 2013 at 12:52:24AM -0500, Mark Salter wrote:
>>> On Tue, 2013-01-29 at 09:05 +0800, Chen Baozi wrote:
>>>> Thanks, Mark. I've switched to another machine which has better
network
>>>> connection. And It finally works, :) I guess something I've checkout
before
>>>> was corrupt due to both my poor network connection and big size of the
>>>> rootfs.
>>>>
>>>> BTW, seems it is not up-to-date? I mean there is no /stage3 under the
rootfs.
>>>
>>> Hmm. I looked closer at the tree I checked out and it too had a head at
>>> commit 3e7ab1bee31082a0 from Al on Dec 31. I'm at a loss to explain
what
>> It is the same with my local git tree.
>>
>>> is going wrong. I have a local tree that appears to be up to date with
>>> the repo on
fedoraproject.org but the log shows 18 commits which aren't
>>> in the tree I cloned from
fedoraproject.org repo earlier today. I'll
try
>>> and see if I can sort it all out tomorrow.
>> Thanks a lot.
>>
>> Baozi
>
> Al, this may be something for you to look at. If I clone the repo using
> http, I get 3e7ab1bee31082a as the lastest commit. If I use ssh+git, I
> get everything correctly.
>
> --Mark
>
>
The only thing I can think of right now is that 'git update-server-info'
may not be getting run on updates to the repo for some reason. I've
run it by hand to see if this changes the behavior -- let me know if
you now get the most recent commit. If not, I'll have to poke the
infrastructure folks. The short term workaround is to use ssh+git,
as you indicated.
Infrastructure and I have been struggling with the underlying problem
that http and git and SELinux are in a bit of a disagreement on how
access should work -- and it's http that's been losing out so far.
Yay. A clone using http did get the latest bits.