Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote:
> On Wed, 27 Feb 2008, Junio C Hamano wrote:
> >
> > I think we can teach the upload-pack side to be more helpful and
> > with a protocol extension to send tag objects that are pointing
> > at commits that will be included in the result, or something
> > like that, though. But that is outside the scope of 1.5.5; it
> > would be a moderate to large protocol surgery, and I suspect it
> > might even have to affect pack-objects.
>
> Using a single connection, either by just telling the remote that you want
> to autofollow tags, and it should therefore include any tags that point to
> any objects it includes,
I agree its outside of 1.5.5, as we'd all like to see 1.5.5 happen
soon, but it could be 1.5.6 material, especially if someone starts
working on it sooner rather than later.
Its actually probably not that difficult to implement. We'd just
want to include a size threshold, to prevent the client from
suddenly receiving a 1M tag (with say a build log embedded in it)
on an otherwise 100K transfer. Autofollowing by having the remote
include the tags in the pack and send to the client would be more
efficient for both sides then autofollowing with a second set of
ref requests, even if we are keeping the current connection open.
I'll try to work up a prototype of this soon, say in the next week.
Obviously not for 1.5.5 but no reason to wait for the 1.5.6/1.6.0
window to open before developing it. I think its a better approach
then supporting a second set of ref requests on the same connection.
_IF_ we are going to support a second set of ref requests on the
same connection then we should also support being able to switch
to another repository. I have 40 some odd repositories at day-job
that a shell script loops over and does fetches in, over SSH.
Setting up and tearing down 40+ SSH connections (especially with tag
following!) sucks[*1*]. I think the X.org folks are in a similar
position as me[*2*].
> If the situation is:
>
> T - tag master
> / /
> O - A - O - O - B
>
> the first fetch will see:
>
> tag: T
> tag^{}: A
> master: B
>
> The issue is that our starting set for our side of the negotiation is our
> current refs, which doesn't include A. I'm suggesting that, for the
> purposes of autofollow, A should be included.
I agree. This is probably easier than coding the protocol extension above.
:-)
*1* I know all about the SSH connection sharing feature, it is
unsupported on Cygwin. I'm on Cygwin at day-job. So that is
a no-go.
*2* X.org users are more likely to be on a UNIX platform where the
OpenSSH connection share code works correctly.
--
Shawn.
-
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
