From: Nicolas Pitre <nico@cam.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/6] Allow pack header preprocessing before unpack-objects/index-pack.
Date: Wed, 01 Nov 2006 22:58:30 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.64.0611012226260.11384@xanadu.home> (raw)
In-Reply-To: <7v3b92zpzj.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Nov 2006, Junio C Hamano wrote:
> Rather nicely done. I see upto 2/6 are identical to what has
> sitting in "pu" for the past few days, modulo some indentation?
Yes. I just inserted them in the serie as I didn't see them in pu until
a very recent pull.
> I wonder how much testing has this series seen, by the way.
It has been tested a bit. At least until it started behaving
correctly for me. There might still be bugs remaining, but nothing that
should screw a repository up. I think it should be good enough for next.
> Also, I wonder what happens after 5/6 errors out. It dies and
> the caller (typically receive-pack) reports it back, which would
> fail the push (and does not update the refs). Retrying in such
> a case would probably use the same set of refs on both ends,
> resulting in exactly the same pack...
Well, the purpose of 5/6 is to avoid creating a .keep file if it already
exists. This is more a security thing so if you decide to mark one of
your pack with .keep (say an history pack that doesn't need to be
repacked) then you don't want a funny git server to send you the same
pack just for the purpose of overwriting the same .keep file (that could
be removed right away if it ends up being considered as a lock file).
This is made more obvious with 6/6 as the .keep file is not removed if
it was there before. So this is not actually an error if creating a
.keep file fails with EEXIST.
As for index-pack dying, it will be reported the same way as
unpack-objects dying -- no difference there. Of course if it dies on
the first push, it is likely to die on all subsequent pushes since the
condition for that to happen is most probably due to a serious problem
(out of disk space, corruption in the existing objects in the
repository, etc).
The pack is put in place with move_temp_to_file() so if a previous
attempt already stored a pack with the same name before successfully
updating corresponding refs then the old pack will silently be kept
since we know both packs contain the same objects when they have the
same name. When a pack is moved it is always complete so there
shouldn't be any (new) instance of repository corruption in normal
circumbstances even in the presence of index-pack dying.
prev parent reply other threads:[~2006-11-02 3:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-01 22:06 [PATCH 1/6] Allow pack header preprocessing before unpack-objects/index-pack Nicolas Pitre
2006-11-01 22:06 ` [PATCH 2/6] Teach receive-pack how to keep pack files based on object count Nicolas Pitre
2006-11-01 22:06 ` [PATCH 3/6] git-fetch can use both --thin and --keep with fetch-pack now Nicolas Pitre
2006-11-01 22:06 ` [PATCH 4/6] improve fetch-pack's handling of kept packs Nicolas Pitre
2006-11-01 22:06 ` [PATCH 5/6] have index-pack create .keep file more carefully Nicolas Pitre
2006-11-01 22:06 ` [PATCH 6/6] remove .keep pack lock files when done with refs update Nicolas Pitre
2006-11-02 5:18 ` Shawn Pearce
2006-11-02 5:27 ` Junio C Hamano
2006-11-02 15:09 ` Nicolas Pitre
2006-11-02 17:25 ` Nicolas Pitre
2006-11-03 9:35 ` Junio C Hamano
2006-11-01 23:50 ` [PATCH 1/6] Allow pack header preprocessing before unpack-objects/index-pack Junio C Hamano
2006-11-02 3:58 ` Nicolas Pitre [this message]
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=Pine.LNX.4.64.0611012226260.11384@xanadu.home \
--to=nico@cam.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).