On Tue, Sep 7, 2010 at 12:57 AM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
> On Mon, 6 Sep 2010, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@xxxxxxxxxxx> writes:
>>
>> >> * enumerate the list of objects associated with an individual commit by:
>> >> i) creating a CUSTOM pack+idx using git pack-objects {ref}
>> >> ii) *parsing* the idx file using gitdb's FileIndex to get the list
>> >> of objects
>> >
>> > That's where you're going so much out of your way to give you trouble.
>> > A simple rev-list would give you that list:
>> >
>> > git rev-list --objects <this_commit> --not <this_commit''s_parents>
>> >
>> > That's it.
>>
>> I didn't want to get into this discussion, but where in the above picture
>> does the usual "want/ack" exchange fit?
>
> Before object enumeration obviously. But I think that Luke has enough
> to play with already by only assuming the easy case for now. If Git P2P
> is to be viable, it has to prove itself at least with the easy case
> first.
:) yes. worry about that later. optimisation. time to think.
idea earlier (from 2 hours ago) unworkable, thought of another one,
split commit list into multi-level "virtual hierarchical
subdirectories" of say 256 entries each. can therefore easily trip
down each "subdirectory" which will quickly get you to the right place
where the commits are different, with only a few roundtrips. sort-of
binary search but 256-way search. binary search not optimal here
because of multiple network round-trips. sorry very obtuse will write
up better.
l.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html