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

[Junio C Hamano <junkio@cox.net>]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Dana How <danahow@gmail.com> 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.

Gee, I do not want to touch this, unless we can do something
about that sleep 2, even if you have & at the end (actually,
especially because you have that -- it makes me worried).

At the minimum, I think you do not have to restamp at all if the
result is a single pack (i.e. the usual case), like so:

case "$restamp" in
?*' '?*)
	# we have more than one.
        # for split packs,  the first created should have most recent timestamp
	for file in $restamp ; do touch $file; sleep 2; done &
	;;
esac

Come to think of it, can't you do this "re-touching" business at
the end of pack-objects without sleeping?  You could keep track
of the names of the packs you produced, and if you have produced
5, like so:

	1
        2
        3
        4
        5

you would swap timestamp of #1 and #5, #2 and #4 using stat()
and utime(), and you are done.  Each of these huge packs would
take more than one second to write it out, but if that is not
the case, you could even start with timestamp of #5, subtract 1
and stamp #4, subtract 1 and stamp #3, ... You may end up using
timestamp from the past, but that would not be a problem.

And I am really hoping that the other "use object density in
reordering" patch would make this irrelevant.  You would have
commit and then the rest in the normal input object stream, and
recenty ordering done by git-pack-objects should keep commits
together early in the resulting split pack, and earlier parts
that have the commits would be hopefully denser.