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?
The biggest trouble before object transfer actually happens is that the
sending end needs to find a set of commits that are known to exist at the
receiving end, but it needs to do that starting from a state where the tip
commits the receiving end has are not known by it. That is why the
receiver must go back in his history and keep asking the sender "I have
this, this, this, this...; now have you heard enough?" until the sender
sees a commit that it knows about. After that happens, it can list them
on its "git rev-list --objects <my tips> --not <he has these>" command
line in order to enumerate objects it needs to send.
If the receiver is purely following the sender, not doing any work on its
own, the tips the receiver has may always be known by the sender, but that
is not an interesting case at all.
--
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