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

From: Junio C Hamano <junkio@cox.net>
Date: May 25, 2007, 03:18 UTC
Message-ID: <7vhcq1si9q.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <56b7f5510705241933x67fd4ed9h6d0e24341c19a9d4@mail.gmail.com>

"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.

Show 6 quoted lines

> 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.