Jonathan Tan [off-list ref] writes:
quoted
For a real implementation, I think we'd want to do the negotiation
inside the conversation between send-pack and receive-pack, so that
what is agreed to be common between two parties will not shift in
the middle (in the same spirit that upload-pack grabs all the
relevant refs first, advertises them, negotiates what is common and
creates a pack, all using the same worldview of where the tips of
refs are throughout the process, even if some refs change in the
meantime).
Upload-pack does that for protocol v0 ssh:// and git:// but not
http(s)://, and does not do that for protocol v2, I believe.
If we were to do that, I don't think it would work for the transports
that have are stateless (e.g. HTTP).
Yeah, I consider it a bug in the "stateless" hack, though, and v2
somehow chose to take the common denominator to propagate the same
bug to protocols that are otherwise capable of being stateful.
In any case, I think I heard in another response from you that you
plan to do only v2, and I think that is OK. Perhaps we can have a
separate service (like 'ls-refs' is a service that can be used
independent of the 'fetch' service in v2, and can be used by
somebody trying to 'push') 'negotiate' that can become a separate
thing, so that "fetch<->upload-pack" conversation would become
ls-refs plus negotiate plus fetch, while "push<->receive-pack"
conversation would become ls-refs plus negotiate plus push?
Thanks.
Jonathan Tan [off-list ref] writes:
quoted
quoted
For a real implementation, I think we'd want to do the negotiation
inside the conversation between send-pack and receive-pack, so that
what is agreed to be common between two parties will not shift in
the middle (in the same spirit that upload-pack grabs all the
relevant refs first, advertises them, negotiates what is common and
creates a pack, all using the same worldview of where the tips of
refs are throughout the process, even if some refs change in the
meantime).
Upload-pack does that for protocol v0 ssh:// and git:// but not
http(s)://, and does not do that for protocol v2, I believe.
If we were to do that, I don't think it would work for the transports
that have are stateless (e.g. HTTP).
Yeah, I consider it a bug in the "stateless" hack, though, and v2
somehow chose to take the common denominator to propagate the same
bug to protocols that are otherwise capable of being stateful.
In any case, I think I heard in another response from you that you
plan to do only v2, and I think that is OK. Perhaps we can have a
separate service (like 'ls-refs' is a service that can be used
independent of the 'fetch' service in v2, and can be used by
somebody trying to 'push') 'negotiate' that can become a separate
thing, so that "fetch<->upload-pack" conversation would become
ls-refs plus negotiate plus fetch,
That does make sense conceptually, although the fact that every
negotiate step could potentially also include a packfile (when fetching,
as we do today) makes things more complicated. (Besides the fact that we
would be making another change in the protocol.)
while "push<->receive-pack"
conversation would become ls-refs plus negotiate plus push?
Thanks.
I guess the idea is to have a push that does not start with a ref
advertisement, therefore making everything more modular? That sounds
reasonable (and does mean that if we ever decide that pushes with
negotiate don't need ref advertisement at all, we can just remove the
ls-refs part), but this sounds like it would require some sort of v2 for
push - which is another discussion topic.