[ANNOUNCE] GIT 1.5.1.1

[ANNOUNCE] GIT 1.5.1.1

[Junio C Hamano]

The latest maintenance release GIT 1.5.1.1 is available at the
usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.1.1.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.1.1.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.1.1.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.1.1-1.$arch.rpm	(RPM)

GIT v1.5.1.1 Release Notes
==========================

Fixes since v1.5.1
------------------

* Documentation updates

  - The --left-right option of rev-list and friends is documented.

  - The documentation for cvsimport has been majorly improved.

  - "git-show-ref --exclude-existing" was documented.

* Bugfixes

  - The implementation of -p option in "git cvsexportcommit" had
    the meaning of -C (context reduction) option wrong, and
    loosened the context requirements when it was told to be
    strict.

  - "git cvsserver" did not behave like the real cvsserver when
    client side removed a file from the working tree without
    doing anything else on the path.  In such a case, it should
    restore it from the checked out revision.

  - "git fsck" issued an alarming error message on detached
    HEAD.  It is not an error since at least 1.5.0.

  - "git send-email" produced of References header of unbounded length;
    fixed this with line-folding.

  - "git archive" to download from remote site should not
    require you to be in a git repository, but it incorrectly
    did.

  - "git apply" ignored -p<n> for "diff --git" formatted
    patches.

  - "git rerere" recorded a conflict that had one side empty
    (the other side adds) incorrectly; this made merging in the
    other direction fail to use previously recorded resolution.

  - t4200 test was broken where "wc -l" pads its output with
    spaces.

  - "git branch -m old new" to rename branch did not work
    without a configuration file in ".git/config".

  - The sample hook for notification e-mail was misnamed.

  - gitweb did not show type-changing patch correctly in the
    blobdiff view.

  - git-svn did not error out with incorrect command line options.

  - git-svn fell into an infinite loop when insanely long commit
    message was found.

  - git-svn dcommit and rebase was confused by patches that were
    merged from another branch that is managed by git-svn.

----------------------------------------------------------------

Changes since v1.5.1 are as follows:

Arjen Laarhoven (4):
      usermanual.txt: some capitalization nits
      t3200-branch.sh: small language nit
      t5300-pack-object.sh: portability issue using /usr/bin/stat
      Makefile: iconv() on Darwin has the old interface

Brian Gernhardt (3):
      Fix t4200-rerere for white-space from "wc -l"
      Document --left-right option to rev-list.
      Distinguish branches by more than case in tests.

Dana How (1):
      Fix lseek(2) calls with args 2 and 3 swapped

Eric Wong (3):
      git-svn: bail out on incorrect command-line options
      git-svn: dcommit/rebase confused by patches with git-svn-id: lines
      git-svn: fix log command to avoid infinite loop on long commit messages

Frank Lichtenheld (7):
      cvsimport: sync usage lines with existing options
      cvsimport: Improve documentation of CVSROOT and CVS module determination
      cvsimport: Improve usage error reporting
      cvsimport: Reorder options in documentation for better understanding
      cvsimport: Improve formating consistency
      cvsserver: small corrections to asciidoc documentation
      cvsserver: Fix handling of diappeared files on update

Geert Bosch (1):
      Fix renaming branch without config file

Gerrit Pape (1):
      rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.

Jakub Narebski (1):
      gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches

Jim Meyering (1):
      (encode_85, decode_85): Mark source buffer pointer as "const".

Julian Phillips (1):
      Documentation: show-ref: document --exclude-existing

Junio C Hamano (7):
      rerere: make sorting really stable.
      Fix dependency of common-cmds.h
      Documentation: tighten dependency for git.{html,txt}
      Prepare for 1.5.1.1
      Add Documentation/cmd-list.made to .gitignore
      fsck: do not complain on detached HEAD.
      GIT 1.5.1.1

Lars Hjemli (2):
      rename_ref(): only print a warning when config-file update fails
      Make builtin-branch.c handle the git config file

René Scharfe (1):
      Revert "builtin-archive: use RUN_SETUP"

Shawn O. Pearce (1):
      Honor -p<n> when applying git diffs

Tomash Brechko (1):
      cvsexportcommit -p : fix the usage of git-apply -C.

Ville Skyttä (1):
      DESTDIR support for git/contrib/emacs

YOSHIFUJI Hideaki (1):
      Avoid composing too long "References" header.

[ANNOUNCE] GIT 1.5.1.2

[Junio C Hamano]

The latest maintenance release GIT 1.5.1.2 is available at the
usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.1.2.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.1.2.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.1.2.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.1.2-1.$arch.rpm	(RPM)

GIT v1.5.1.2 Release Notes
==========================

Fixes since v1.5.1.1
--------------------

* Bugfixes

  - "git clone" over http from a repository that has lost the
    loose refs by running "git pack-refs" were broken (a code to
    deal with this was added to "git fetch" in v1.5.0, but it
    was missing from "git clone").

  - "git diff a/ b/" incorrectly fell in "diff between two
    filesystem objects" codepath, when the user most likely
    wanted to limit the extent of output to two tracked
    directories.

  - git-quiltimport had the same bug as we fixed for
    git-applymbox in v1.5.1.1 -- it gave an alarming "did not
    have any patch" message (but did not actually fail and was
    harmless).

  - various git-svn fixes.

  - Sample update hook incorrectly always refused requests to
    delete branches through push.

  - git-blame on a very long working tree path had buffer
    overrun problem.

  - git-apply did not like to be fed two patches in a row that created
    and then modified the same file.

  - git-svn was confused when a non-project was stored directly under
    trunk/, branches/ and tags/.

  - git-svn wants the Error.pm module that was at least as new
    as what we ship as part of git; install ours in our private
    installation location if the one on the system is older.

  - An earlier update to command line integer parameter parser was
    botched and made 'update-index --cacheinfo' completely useless.


* Documentation updates

  - Various documentation updates from J. Bruce Fields, Frank
    Lichtenheld, Alex Riesen and others.  Andrew Ruder started a
    war on undocumented options.


----------------------------------------------------------------

Changes since v1.5.1.1 are as follows:

Alex Riesen (3):
      Use rev-list --reverse in git-rebase.sh
      Document -g (--walk-reflogs) option of git-log
      Fix overwriting of files when applying contextually independent diffs

Andrew Ruder (8):
      Update git-am documentation
      Update git-applymbox documentation
      Update git-apply documentation
      Update git-annotate/git-blame documentation
      Update git-archive documentation
      Update git-cherry-pick documentation
      Fix unmatched emphasis tag in git-tutorial
      Update git-config documentation

Andy Whitcroft (1):
      fix up strtoul_ui error handling

Carlos Rica (1):
      Use const qualifier for 'sha1' parameter in delete_ref function

Eric Wong (4):
      git-svn: respect lower bound of -r/--revision when following parent
      git-svn: quiet some warnings when run only with --version/--help
      git-svn: don't allow globs to match regular files
      perl: install private Error.pm if the site version is older than our own

Eygene Ryabinkin (2):
      Teach gitk to use the user-defined UI font everywhere.
      Improve look-and-feel of the gitk tool.

Frank Lichtenheld (5):
      config.txt: Document gitcvs.allbinary
      config.txt: Document core.autocrlf
      config.txt: Change pserver to server in description of gitcvs.*
      config.txt: Fix grammatical error in description of http.noEPSV
      git-shortlog: Fix two formatting errors in asciidoc documentation

Gerrit Pape (2):
      variable $projectdesc needs to be set before checking against unchanged default.
      Have sample update hook not refuse deleting a branch through push.

J. Bruce Fields (7):
      Documentation: minor edits of git-lost-found manpage
      Documentation: clarify git-checkout -f, minor editing
      Documentation: clarify track/no-track option.
      user-manual: fix discussion of default clone
      user-manual: detached HEAD
      user-manual: start revising "internals" chapter
      user-manual: use detached head when rewriting history

Jim Meyering (1):
      sscanf/strtoul: parse integers robustly

Junio C Hamano (4):
      Do not default to --no-index when given two directories.
      Start preparing for 1.5.1.2
      git-clone: fix dumb protocol transport to clone from pack-pruned ref
      GIT 1.5.1.2

Linus Torvalds (1):
      git-quiltimport complaining yet still working

Matthias Lederhofer (1):
      handle_options in git wrapper miscounts the options it handled.

Michael Spang (1):
      git-blame: Fix overrun in fake_working_tree_commit()

Sam Vilain (1):
      git-tar-tree: complete deprecation conversion message

Shawn O. Pearce (1):
      git-gui: Brown paper bag fix division by 0 in blame

Re: [ANNOUNCE] GIT 1.5.1.2

[Linus Torvalds]

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.

As a result, nothing really works, ie:

	[torvalds@hera git.git]$ git log
	error: Could not read 42c4b58059fa9af65e90f2c418bb551e30d1d32f

and doing a "git pull" will just result in lots of

	error: refs/heads/maint does not point to a valid object!
	error: refs/heads/next does not point to a valid object!
	error: refs/heads/todo does not point to a valid object!
	...

which is perhaps a bit of a misleading error message (technically true, 
but ..)

Oops.

		Linus

Re: [ANNOUNCE] GIT 1.5.1.2

[Junio C Hamano]

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

> 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.

I've run fsck and then flipped the bits manually on these files
to unblock people, but I have no idea how this happened.  These
two were the only files that had the funny bits in the
repository.

        -r-------- 1 junio junio  1120880 Apr 22 06:46
        -r-------- 1 junio junio 15709370 Apr 22 06:46

I can tell from the output of "last" on that machine that I was
present and I am reasonably sure this was from "git repack -a -d"
I manually did.  But my umask is 0002...

Gaah.  "git repack -a -d" from 'master' leaves packs with 0400
mode (maint is fine).

> Oops.

Oops indeed.

Today's 'master' leaves .idx/.pack in 0400

[Junio C Hamano]

With recent glibc, mkstemp() creates 0400 file.  Updated
pack-objects uses it in pack/idx writing without fixing this,
hence this problem.

Will have a fix hopefully shortly.

Re: Today's 'master' leaves .idx/.pack in 0400

[Nicolas Pitre]

On Sun, 22 Apr 2007, Junio C Hamano wrote:

> With recent glibc, mkstemp() creates 0400 file.  Updated
> pack-objects uses it in pack/idx writing without fixing this,
> hence this problem.

Oops.  I guess I'm guilty for this.  I didn't bother looking at the 
permission on the pack for git-pack-objects since git-repack seemed to 
take care of that.  But it only _remove_ write permissions.


Nicolas

Re: Today's 'master' leaves .idx/.pack in 0400

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Sun, 22 Apr 2007, Junio C Hamano wrote:
>
>> With recent glibc, mkstemp() creates 0400 file.  Updated
>> pack-objects uses it in pack/idx writing without fixing this,
>> hence this problem.
>
> Oops.  I guess I'm guilty for this.  I didn't bother looking at the 
> permission on the pack for git-pack-objects since git-repack seemed to 
> take care of that.  But it only _remove_ write permissions.

Ok, then probably we can change the 0444 in my "quickfix" patch
to 0644.  That should also let the 5300 test pass.

Re: Today's 'master' leaves .idx/.pack in 0400

[Nicolas Pitre]

On Sun, 22 Apr 2007, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Sun, 22 Apr 2007, Junio C Hamano wrote:
> >
> >> With recent glibc, mkstemp() creates 0400 file.  Updated
> >> pack-objects uses it in pack/idx writing without fixing this,
> >> hence this problem.
> >
> > Oops.  I guess I'm guilty for this.  I didn't bother looking at the 
> > permission on the pack for git-pack-objects since git-repack seemed to 
> > take care of that.  But it only _remove_ write permissions.
> 
> Ok, then probably we can change the 0444 in my "quickfix" patch
> to 0644.  That should also let the 5300 test pass.

Well, actually there is no point making pack files writable.  If they're 
modified, they get corrupted.

Here's the fix I wanted to propose:

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index c72e07a..85c6e6e 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1786,11 +1786,13 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 		if (rename(pack_tmp_name, tmpname))
 			die("unable to rename temporary pack file: %s",
 			    strerror(errno));
+		chmod(tmpname, 0444);
 		snprintf(tmpname, sizeof(tmpname), "%s-%s.idx",
 			 base_name, sha1_to_hex(object_list_sha1));
 		if (rename(idx_tmp_name, tmpname))
 			die("unable to rename temporary index file: %s",
 			    strerror(errno));
+		chmod(tmpname, 0444);
 		puts(sha1_to_hex(object_list_sha1));
 	}
 	if (progress)


Nicolas

Re: Today's 'master' leaves .idx/.pack in 0400

[Nicolas Pitre]

On Sun, 22 Apr 2007, Nicolas Pitre wrote:

> On Sun, 22 Apr 2007, Junio C Hamano wrote:
> 
> > Nicolas Pitre <nico@cam.org> writes:
> > 
> > > On Sun, 22 Apr 2007, Junio C Hamano wrote:
> > >
> > >> With recent glibc, mkstemp() creates 0400 file.  Updated
> > >> pack-objects uses it in pack/idx writing without fixing this,
> > >> hence this problem.
> > >
> > > Oops.  I guess I'm guilty for this.  I didn't bother looking at the 
> > > permission on the pack for git-pack-objects since git-repack seemed to 
> > > take care of that.  But it only _remove_ write permissions.
> > 
> > Ok, then probably we can change the 0444 in my "quickfix" patch
> > to 0644.  That should also let the 5300 test pass.
> 
> Well, actually there is no point making pack files writable.  If they're 
> modified, they get corrupted.

OK there are those test cases.

Well...  Either we chmod to 0644, or we fix the tests to 'chmod +w' like 
it is already done in t5302.

In any case I wouldn't die() but only error() on a failure to chmod().  
It is sure inconvenient if the pack isn't world readable, but it is not 
a "fatal" problem for the repack.


Nicolas

Re: [ANNOUNCE] GIT 1.5.1.2

[Junio C Hamano]

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

> 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-<.

Re: Today's 'master' leaves .idx/.pack in 0400

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Sun, 22 Apr 2007, Nicolas Pitre wrote:
>
>> On Sun, 22 Apr 2007, Junio C Hamano wrote:
>> 
>> > Nicolas Pitre <nico@cam.org> writes:
>> > 
>> > > On Sun, 22 Apr 2007, Junio C Hamano wrote:
>> > >
>> > >> With recent glibc, mkstemp() creates 0400 file.  Updated
>> > >> pack-objects uses it in pack/idx writing without fixing this,
>> > >> hence this problem.
>> > >
>> > > Oops.  I guess I'm guilty for this.  I didn't bother looking at the 
>> > > permission on the pack for git-pack-objects since git-repack seemed to 
>> > > take care of that.  But it only _remove_ write permissions.
>> > 
>> > Ok, then probably we can change the 0444 in my "quickfix" patch
>> > to 0644.  That should also let the 5300 test pass.
>> 
>> Well, actually there is no point making pack files writable.  If they're 
>> modified, they get corrupted.
>
> OK there are those test cases.
>
> Well...  Either we chmod to 0644, or we fix the tests to 'chmod +w' like 
> it is already done in t5302.
>
> In any case I wouldn't die() but only error() on a failure to chmod().  
> It is sure inconvenient if the pack isn't world readable, but it is not 
> a "fatal" problem for the repack.

If it DIED, I would not have to have been embarrassed in public
like this!

Grumble.

Re: Today's 'master' leaves .idx/.pack in 0400

[Linus Torvalds]

On Sun, 22 Apr 2007, Nicolas Pitre wrote:
> 
> Well, actually there is no point making pack files writable.  If they're 
> modified, they get corrupted.
> 
> Here's the fix I wanted to propose:
> 
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index c72e07a..85c6e6e 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1786,11 +1786,13 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
>  		if (rename(pack_tmp_name, tmpname))
>  			die("unable to rename temporary pack file: %s",
>  			    strerror(errno));
> +		chmod(tmpname, 0444);

I think this is wrong (as is Junio's). I think we should still honor the 
repository permission setting, and default to honoring umask.

So I think that if the user has a umask that says "nobody else can read", 
then we should *not* make it world readable (unless the 
"shared_repository" thing is set to override it, of course).

		Linus

Re: Today's 'master' leaves .idx/.pack in 0400

[Junio C Hamano]

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

> On Sun, 22 Apr 2007, Nicolas Pitre wrote:
>> 
>> Well, actually there is no point making pack files writable.  If they're 
>> modified, they get corrupted.
>> 
>> Here's the fix I wanted to propose:
>> 
>> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
>> index c72e07a..85c6e6e 100644
>> --- a/builtin-pack-objects.c
>> +++ b/builtin-pack-objects.c
>> @@ -1786,11 +1786,13 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
>>  		if (rename(pack_tmp_name, tmpname))
>>  			die("unable to rename temporary pack file: %s",
>>  			    strerror(errno));
>> +		chmod(tmpname, 0444);
>
> I think this is wrong (as is Junio's). I think we should still honor the 
> repository permission setting, and default to honoring umask.
>
> So I think that if the user has a umask that says "nobody else can read", 
> then we should *not* make it world readable (unless the 
> "shared_repository" thing is set to override it, of course).

I obviously agree, but as a tentative measure, I'll push out
0644 version anyway.

Re: Today's 'master' leaves .idx/.pack in 0400

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> So I think that if the user has a umask that says "nobody else can read", 
>> then we should *not* make it world readable (unless the 
>> "shared_repository" thing is set to override it, of course).
>
> I obviously agree, but as a tentative measure, I'll push out
> 0644 version anyway.

How about this as a replacement (hot off the press -- still
running the tests).

-- >8 --
pack-objects: adjust the permission bits of created files.

The updated pack-objects let mkstemp() to create new pack/idx
pair, without fixing the permission bits on them.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 builtin-pack-objects.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index c72e07a..34350bf 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1612,6 +1612,13 @@ static void get_object_list(int ac, const char **av)
 	traverse_commit_list(&revs, show_commit, show_object);
 }
 
+static int adjust_perm(const char *path, mode_t mode)
+{
+	if (chmod(path, mode))
+		return -1;
+	return adjust_shared_perm(path);
+}
+
 int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 {
 	int depth = 10;
@@ -1780,14 +1787,25 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 	last_obj_offset = write_pack_file();
 	if (!pack_to_stdout) {
 		unsigned char object_list_sha1[20];
+		mode_t mode = umask(0);
+
+		umask(mode);
+		mode = 0666 & ~mode;
+
 		write_index_file(last_obj_offset, object_list_sha1);
 		snprintf(tmpname, sizeof(tmpname), "%s-%s.pack",
 			 base_name, sha1_to_hex(object_list_sha1));
+		if (adjust_perm(pack_tmp_name, mode))
+			die("unable to make temporary pack file readable: %s",
+			    strerror(errno));
 		if (rename(pack_tmp_name, tmpname))
 			die("unable to rename temporary pack file: %s",
 			    strerror(errno));
 		snprintf(tmpname, sizeof(tmpname), "%s-%s.idx",
 			 base_name, sha1_to_hex(object_list_sha1));
+		if (adjust_perm(idx_tmp_name, mode))
+			die("unable to make temporary index file readable: %s",
+			    strerror(errno));
 		if (rename(idx_tmp_name, tmpname))
 			die("unable to rename temporary index file: %s",
 			    strerror(errno));

Re: Today's 'master' leaves .idx/.pack in 0400

[Linus Torvalds]

On Sun, 22 Apr 2007, Junio C Hamano wrote:
> 
> How about this as a replacement (hot off the press -- still
> running the tests).

Looks good, but..

> +		mode_t mode = umask(0);
> +
> +		umask(mode);
> +		mode = 0666 & ~mode;

I would really suggest just defaulting to

	mode = 0444 & ~mode;

since there simply is never any reason to allow a writable pack-file.

The fact that we have some tests that try to corrupt a pack-file is not 
really a reason. Just make them do "chmod +w" before corrupting it.

But your patch is an obvious improvement regardless, so I certainly don't 
think this is a *big* issue.

		Linus