Re: Subject: [PATCH] git-merge-pack

[Junio C Hamano <gitster@pobox.com>]

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 that is a false sense of "ok, we will be able to do
something else in the background meantime", which is not so
useful in practice.

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