On Fri, May 09, 2008 at 01:41:30AM +0000, Brandon Casey wrote:
> Here's what I was thinking (posted using gmane):
>
> diff --git a/git-repack.sh b/git-repack.sh
> index e18eb3f..064c331 100755
> --- a/git-repack.sh
> +++ b/git-repack.sh
I like it. It makes an easy rule to say "packed objects _never_ get
pruned, they only get demoted to loose objects." And then of course
we have sane rules for pruning loose objects.
> - rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
> + rm -f "$PACKDIR/old-pack-$name.idx"
> + test -z "$keep_unreachable" ||
> + ! test -f "$PACKDIR/old-pack-$name.pack" ||
> + git unpack-objects < "$PACKDIR/old-pack-$name.pack" || {
> + echo >&2 "Failed unpacking unreachable objects from old pack"
> + echo >&2 "saved as old-pack-$name.pack in $PACKDIR."
> + exit 1
> + }
> + rm -f "$PACKDIR/old-pack-$name.pack"
> [...]
>
> Is the first invocation of unpack-objects necessary? pack-objects has created
> a pack which hashes to the same name of a pack we already have, and we replace
> the original with the new one. Is that what is happening? They will be
> identical right?
Yeah, that's what it looks like to me (that the first unpack is
unnecessary, because we will just be putting the new pack into place
that has all the same objects). AIUI, two packs with identical hashes
must contain the exact same objects.
> Of course this won't set the timestamp on the created objects based on the
> timestamp of the pack file, but this was easy. Setting the timestamp would be
> proper, but what's another two weeks. Besides, for those users not manually
> running git-gc, this code path won't even be executed until there are enough
> pack files for git-gc to add -A to the repack options.
I think the extra two weeks is fine.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
