[PATCH] Split packs from git-repack should have descending timestamps

If git-repack produces multiple split packs because
--max-pack-size was in effect,  the first pack written
should have the latest timestamp because:
(1) sha1_file.c:rearrange_packed_git() puts more recent
    pack files at the beginning of the search list;  and
(2) the most recent objects are written out first
    while packing.

This is based on next rather than master to avoid merge
conflicts with changes already in git-repack.sh due to
the --max-pack-size patchset.

Signed-off-by: Dana L. How <redacted>
---
 git-repack.sh |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git-repack.sh b/git-repack.sh
index 4ea6e5b..953de4a 100755
--- a/git-repack.sh
+++ b/git-repack.sh

@@ -68,6 +68,7 @@ names=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP")
 if [ -z "$names" ]; then
 	echo Nothing new to pack.
 fi
+restamp=
 for name in $names ; do
 	chmod a-w "$PACKTMP-$name.pack"
 	chmod a-w "$PACKTMP-$name.idx"

@@ -94,8 +95,12 @@ for name in $names ; do
 		exit 1
 	}
 	rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
+	restamp="$PACKDIR/pack-$name.pack $restamp"
 done
 
+# for split packs,  the first created should have most recent timestamp
+for file in $restamp ; do touch $file ; sleep 2; done &
+
 if test "$remove_redundant" = t
 then
 	# We know $existing are all redundant.

-- 
1.5.2.762.gd8c6-dirty

Dana How [off-list ref] wrote:

If git-repack produces multiple split packs because
--max-pack-size was in effect,  the first pack written
should have the latest timestamp because:
(1) sha1_file.c:rearrange_packed_git() puts more recent
    pack files at the beginning of the search list;  and
(2) the most recent objects are written out first
    while packing.

This is based on next rather than master to avoid merge
conflicts with changes already in git-repack.sh due to
the --max-pack-size patchset.

Ack.  Given our mtime based sorting routine, even without your
recent patch to improve it, I think we definately want this type
of behavior built into git-repack.sh.  Good follow-on to your
--max-pack-size series.

-- 
Shawn.