Daniel Barkalow [off-list ref] writes:
The idea is to keep the open connection in the data for the transport in
between getting the list of refs and doing anything further. This
therefore moves the connection-handling aspects outside of fetch-pack()
and handles them primarily in transport.c.
The idea is very sound. The scripted version of git-fetch used
a separate ls-remote only because peek-remote and fetch-pack
were separate programs.
... In particular, I don't know if there's a way to have the
connection end up in a state where objects for more refs can be requested
after some refs have been requested and the resulting objects read.
The upload-pack protocol goes "S: here are what I have, C: I
want these, C: I have these, S: ok, continue, C: I have these,
S: ok, continue, C: I have these, S: ok, I've heard enough, C:
done, S: packfile is here", so after packfile generation starts
there is nothing further the downloader can say.
Otherwise you would be able to do the tag following using the
same connection, but that is unfortunately not a case.
On Mon, 5 Nov 2007, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
The idea is to keep the open connection in the data for the transport in
between getting the list of refs and doing anything further. This
therefore moves the connection-handling aspects outside of fetch-pack()
and handles them primarily in transport.c.
The idea is very sound. The scripted version of git-fetch used
a separate ls-remote only because peek-remote and fetch-pack
were separate programs.
I figured that had to be the case, due to the way the protocol acts at the
beginning.
quoted
... In particular, I don't know if there's a way to have the
connection end up in a state where objects for more refs can be requested
after some refs have been requested and the resulting objects read.
The upload-pack protocol goes "S: here are what I have, C: I
want these, C: I have these, S: ok, continue, C: I have these,
S: ok, continue, C: I have these, S: ok, I've heard enough, C:
done, S: packfile is here", so after packfile generation starts
there is nothing further the downloader can say.
Otherwise you would be able to do the tag following using the
same connection, but that is unfortunately not a case.
It would be nice if this could continue: "C: I also want these, S: ok,
heard enough, C: done, S: another packfile is here"; we should be able to
identify the end of the packfile on both ends to resume doing other
things.
Or, maybe, "C: I also want these single objects, S: here's a thin pack of
them", since it's exclusively tags pointing to objects we have just
gotten.
-Daniel
*This .sig left intentionally blank*
Junio C Hamano schrieb:
Daniel Barkalow [off-list ref] writes:
quoted
... In particular, I don't know if there's a way to have the
connection end up in a state where objects for more refs can be requested
after some refs have been requested and the resulting objects read.
The upload-pack protocol goes "S: here are what I have, C: I
want these, C: I have these, S: ok, continue, C: I have these,
S: ok, continue, C: I have these, S: ok, I've heard enough, C:
done, S: packfile is here", so after packfile generation starts
there is nothing further the downloader can say.
Otherwise you would be able to do the tag following using the
same connection, but that is unfortunately not a case.
How about:
S: here are what I have
C: I want these
C: want tags <-- new
C: I have these
S: ok, continue
C: I have these
S: ok, continue
C: I have these
S: ok, these are the tags <-- new
S: I've heard enough
C: done
S: packfile is here
The tags that the server provides are those (and only those[*]) that
reference objects in the packfile that it's going to send.
[*] This way the client doesn't have to figure out which tags it wants; as a
side-effect it won't accidentally fetch tags for objects that it happens to
have in the repository, but aren't reachable from any ref (like what used to
happen).
-- Hannes