threads / patch / 3377

patchgit-repack question

Subject: [PATCH] git-repack question

## tl;dr

3 messages between Feb 17, 2006 and Feb 18, 2006. Diffs are folded; open one to read it.

replies: 2people: 3as markdown or json

linux@horizon.com· Feb 17, 2006, 21:38 UTC · lore

I'm trying to imagine when you'd want to run git-repack without the -d option, or without running git-prune-packed afterwards. (Isn't the idea behind packs to save space?)

I'll leave changing the default to wiser heads, but this trivial patch will at least allow the normal operations to be performed with one command.

Oh, and is the failure to support getopt-style concatenated single-letter options (git-repack -dp) a deliberate design feature of git, or just laziness?

(Legalese: Patch placed in the public domain; copyright abandoned.)

Show changes to 2 files +11 −2

Documentation/git-repack.txt, git-repack.sh

diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 9060fe8..1b1f50d 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -47,6 +47,10 @@ OPTIONS
         Do not update the server information with
         `git update-server-info`.
 
+-p::
+	After packing, run gitlink:git-prune-packed[1] to delete
+	redundant unpacked objects.
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/git-repack.sh b/git-repack.sh
index 1fafb6e..361c7e9 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,10 +3,10 @@
 # Copyright (c) 2005 Linus Torvalds
 #
 
-USAGE='[-a] [-d] [-l] [-n]'
+USAGE='[-a] [-d] [-l] [-n] [-p]'
 . git-sh-setup
 	
-no_update_info= all_into_one= remove_redundant= local=
+no_update_info= all_into_one= remove_redundant= local= prune=
 while case "$#" in 0) break ;; esac
 do
 	case "$1" in
@@ -14,6 +14,7 @@ do
 	-a)	all_into_one=t ;;
 	-d)	remove_redundant=t ;;
 	-l)	local=t ;;
+	-p)	prune=t ;;
 	*)	usage ;;
 	esac
 	shift
@@ -76,6 +77,10 @@ then
 	fi
 fi
 
+case "$prune" in
+t) git-prune-packed ;;
+esac
+
 case "$no_update_info" in
 t) : ;;
 *) git-update-server-info ;;

Linus Torvalds· Feb 17, 2006, 22:20 UTC · re: linux@horizon.com · lore

Re: [PATCH] git-repack question

On Fri, 17 Feb 2006, linux@horizon.com wrote:

>
> I'm trying to imagine when you'd want to run git-repack without the -d
> option, or without running git-prune-packed afterwards.
> (Isn't the idea behind packs to save space?)

Normally you'd always run git-prune-packed.

The reason it doesn't do that is simply being anally careful, and because conceptually the pruning phase is totally independent.

For example, in an environment that mirrors out git repositories by rsync, it can make sense to wait with pruning until the mirror cycle has finished, so that all mirrors always have all the objects.

(I don't do it for the kernel, because (a) I'm a lazy bastard, (b) I'm so confused that I sometimes forget my own name, much less to prune things a day after I've repacked them and (c) I don't care that much about rsync anyway, since you can't avoid some of the _other_ races).

As to whether you'd normally run "-d" - usually you'd run it whenever you pair it up with "-a". When you do an incremental re-pack, "-d" won't do anything anyway.

Again, it might make sense to not delete the old packs when repacking everything in a rsync'ing environment - or even in a shared repository, where removing a pack-file could race with somebody else working on it.

Basically, the default ends up being to never remove any objects at all, simply because that's the _safe_ thing to do.

In practice, I personally always do

	git repack -a -d
	git prune-packed

together, because the full repack isn't _that_ expensive for me (I tend to have lots of cpu power), and because I can't be bothered to worry too much about rsync and there are never any other users working on my git trees.

		Linus

Junio C Hamano· Feb 18, 2006, 06:50 UTC · re: linux@horizon.com · lore

Re: [PATCH] git-repack question

linux@horizon.com writes:

> (Legalese: Patch placed in the public domain; copyright abandoned.)

The rest of the patch looks good, but I'd rather prefer a patch with a proper sign-off, strongly prefereable with a real name so that we can attach blame on later when another SCO happens ;-).