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

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

"Dana How" <danahow@gmail.com> writes:

> Also,  if there are rules on allowable bash constructs
> (POSIX only, no &, etc),  perhaps they should go in
> SubmittingPatches near the new C99 comments?

No bash arrays, no "function" noisewords, limiting <funky> in
${word<funky>word} constructs to POSIX (that means +,-,#,##,%,%%
but no regexps), prefer "test" over "[" (the last one is just for
readability).

But the reason I barfed on "&" is not about the syntax nor
portability.  I was afraid of somebody else manipulating things
long after the parent "git-repack" returns (but still the
stamper sleeping and waiting to restamp the next one) and gets
confused.  In this particular case, the restamping is only about
the performance so it is not _too_ bad, but in general I really
do not like leftover processes still doing something in the
background when the user thinks everything is done.

> I understand your point,  but for a "normal" yet extremely
> large repository this may not be the case.  The "object density"
> patch is designed so that the density component of the sort
> key is extremely weak -- I think the timestamp is very revealing,
> and should be followed in the absence of large variations
> in object density.

I still think "a pack that has ONLY megablobs and mark it with
.keep" is much simpler approach, and there is no question that
density would work extremely well with that kind of arrangement.