Nicolas Pitre [off-list ref] writes:
Why not just parse the pack header in receive-pack / fetch-pack, and
decide on the first-hand information? Sure the pack header is then
gone, but then the only thing that is needed is an extra flag to both
unpack-objects and index-pack to tell them that we've already parsed the
pack header and that the pack version is x and the number of objects is
y. Simply something like --pack_header=x,y. No protocol extension
needed, no extra rev-list, no reliance on the remote server providing
the needed info.
I like it.
Because that approach assumes recieve-pack and unpack-objects
and index-pack are from the same vintage (otherwise your
receive-pack would need to have a way to see if unpack-objects
and index-pack would grok --pack_header argument), we could even
get away without passing the pack version if we wanted to.
Junio C Hamano [off-list ref] wrote:
Nicolas Pitre [off-list ref] writes:
quoted
Why not just parse the pack header in receive-pack / fetch-pack, and
decide on the first-hand information? Sure the pack header is then
gone, but then the only thing that is needed is an extra flag to both
unpack-objects and index-pack to tell them that we've already parsed the
pack header and that the pack version is x and the number of objects is
y. Simply something like --pack_header=x,y. No protocol extension
needed, no extra rev-list, no reliance on the remote server providing
the needed info.
I like it.
Because that approach assumes recieve-pack and unpack-objects
and index-pack are from the same vintage (otherwise your
receive-pack would need to have a way to see if unpack-objects
and index-pack would grok --pack_header argument), we could even
get away without passing the pack version if we wanted to.
Heh. On Saturday I almost did exactly what Nico proposes above.
But I thought both of you would find the --pack_header=x,y option
too brittle and would reject the change.
But since all three of us liked the same idea I'll code it up
and resend my receive-pack patch using Nico's suggestion instead.
Hopefully I'll get it out tomorrow.
BTW I think we do need to pass the pack version in the option.
If we ever do increment the pack version its going to be after this
option is introduced so supporting the option does not imply that
the callee is able to parse the pack file without knowing what
version the file is, especially if the callee supports both the
current version and the new version.
--