On Thu, 6 Sep 2007, Junio C Hamano wrote:

quoted text
> Nicolas Pitre <nico@cam.org> writes:
> 
> > I wonder if this is the best way to go.  In the context of a really fast 
> > repack happening automatically after (or during) user interactive 
> > operations, the above seems a bit heavyweight and slow to me.
> 
> Honestly, I do not believe in that mode of operation that much.
> 
> "While the user is waiting for the EDITOR"?
> 
> Because you do not know how much time you will be given before
> you start, unless
> 
>  (1) your process can be snapshotted and you can restart at the
>      next chance; or
> 
>  (2) it is so cheap and you can afford to abort and start over
>      from scratch at the next chance; or
> 
>  (3) it is so quick that you can simply have the user wait until
>      you are done without adding too much latency to be annoying,
>      when you cannnot finish before the EDITOR come back;

I think we have to aim for #3.  "Automatic" certainly doesn't imply "can 
be slow".  It should be reasonably instantaneous, otherwise it'll become 
annoying quickly enough.  If it can't be (almost) instantaneous in 99% 
of normal cases, then I think it simply should be remain asynchronously 
througha manual invokation of 'git gc' and we only need to teach/remind 
people about it more strongly.

quoted text
> >> An obvious next steps that can be done in parallel by interested
> >> parties would be:
> >> 
> >>  (1) come up with a way to give "name" aka "clustering cue" (I
> >>      think this is very hard);
> >
> > It is, and IMHO not worth it.  If you do it separately from the usual 
> > pack-objects process you'll perform extra IO and decompression when 
> > walking tree objects just to reconstruct those paths, becoming really 
> > slow by the context definition I provided above.
> 
> Well, I said "name" in quotes because you do _NOT_ have to give
> the real name.  I was not thinking about doing the actual tree
> traversal at all.  What you need to do is to come up with a
> token that is the same for the objects in the same deltification
> chain so that they cluster together, and that should be doable
> by looking at the delta chain patterns inside a packfile.

Obviously!  Sorry for being slow.

But I still think that a single repack pass should already be able to 
pick loose objects and selected (small) packs, and produce a pack with 
them all.  No need for a separate merge-pack I'd say.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html