Re: [ANNOUNCE] GIT 1.5.1.2

From: Junio C Hamano <junkio@cox.net>
Date: Apr 22, 2007, 18:47 UTC
Message-ID: <7v7is4nt47.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <alpine.LFD.0.98.0704221019100.9964@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 17 quoted lines

> On Sat, 21 Apr 2007, Junio C Hamano wrote:
>>
>> The latest maintenance release GIT 1.5.1.2 is available at the
>> usual places:
>
> Well, by "available" you probably mean "not available", because it doesn't 
> actually work.
>
> I get EPERM on pack-e00affefe0f779d0f9b0507aef25a1733f4a9117.idx/pack, 
> because they are
>
> 	-r-------- 1 junio junio  1120880
> 	-r-------- 1 junio junio 15709370
>
> respectively.
> ...
> Oops.

Ok, to clarify the situation.

 * This breakage does not make v1.5.1.2 is a dud release, as what
   caused this is not contained in it.

 * A topic to update git-pack-objects has been cooking in 'next'
   and it graduated to 'master' last night after v1.5.1.2 was
   cut from 'maint'.  This series had a bug that left permission
   bits as set by mkstemp(); newer glibc leaves it as 0600.

 * I almost always run 'master' on kernel.org; I ran "git-repack
   -a -d" there using 'master' that contained the breakage.

 * git-repack lets git-pack-objects to create pack/idx, and then
   drops the write permission bits from them.  That is how they
   got 0400.

 * I've fixed the pack/idx 0444 manually at kernel.org; the
   repository has already mirrored out to git.kernel.org, so
   people should be able to fetch from there now.  alt-git.git
   at repo.or.cz should be usable as well, although I suspect
   the site did not even have this issue.

 * I sent a quickfix as a workaround.  Because we rely on
   git-repack to drop write permissions anyway, and some tests
   to plumbing expects the resulting files to be writable by the
   owner, tweaking 0444 in the quickfix to 0644 would be a good
   workaround to fix the problem -and- pass all the test.

So I'll push out a 0644 quickfix on 'master' shortly.

However.

 * To reiterate, people planning to update to v1.5.1.2 should
   not be alarmed with this gotcha.  That comes from the
   maintenance branch and is not affected by this breakage.

 * Letting mkstemp() to create the file and then forcing 0644 is
   not strictly correct, as it makes the files created by people
   with 007 umask readable to the general public.  The code
   before mkstemp() conversion was aware of this issue and used
   open(..., 0666) to let the user's umask applied, I think.

So while the quickfix is an improvement, it not a real fix X-<.