user/sven/git.git/upload-pack.c, branch v1.0rc1

Be careful when dereferencing tags.

2005-11-03T00:50:58Z

One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano

fix multi_ack.

2005-10-29T05:57:01Z

Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

git-upload-pack: Support the multi_ack protocol

2005-10-29T05:57:00Z

This implements three things (trying very hard to be backwards compatible): It sends the "multi_ack" capability via the mechanism proposed by Sergey Vlasov. When the client sends "multi_ack" with at least one "want", multi_ack is enabled. When multi_ack is enabled, "continue" is appended to each "ACK" until either the server can not store more refs, or "done" is received. In contrast to the original protocol, as long as "continue" is sent, flushes are answered by a "NAK" (not just until an "ACK" was sent), and if "continue" was sent at least once, the last message is an "ACK" without "continue". Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

git-upload-pack: More efficient usage of the has_sha1 array

2005-10-29T05:56:59Z

This patch is based on Junio's proposal. It marks parents of common revs so that they do not clutter up the has_sha1 array. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Fix cloning (memory corruption)

2005-10-26T18:52:19Z

upload-pack would set create_full_pack=1 if nr_has==0, but would ask later if nr_needs Signed-off-by: Junio C Hamano

upload-pack: tighten request validation.

2005-10-26T06:53:28Z

This makes sure what the other end asks for are among what we offered to give them. Otherwise we would end up running git-rev-list with 20-byte nonsense, only to find it either die (because the object was not found) or waste time (because we ended up serving that phony 'client'). Also avoid wasting needs_sha1 pool to record duplicates, and detect cloning requests better. [this used to be on top of Johannes fetch-pack enhancements, which we are rewinding it for further testing for now, so the commit is rebased.] Signed-off-by: Junio C Hamano

Revert recent fetch-pack/upload-pack updates.

2005-10-25T21:55:24Z

Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: Junio C Hamano

upload-pack: fix thinko in common-commit finder code.

2005-10-24T22:13:38Z

The code to check if we have the object the other side has was bogus (my fault). Signed-off-by: Junio C Hamano

git-upload-pack: Support sending multiple ACK messages

2005-10-24T22:13:37Z

The current fetch/upload protocol works like this: - client sends revs it wants to have via "want" messages - client sends a flush message (message with len 0) - client sends revs it has via "have" messages - after one window (32 revs), a flush is sent - after each subsequent window, a flush is sent, and an ACK/NAK is received. (NAK means that server does not have any of the transmitted revs; ACK sends also the sha1 of the rev server has) - when the first ACK is received, client sends "done", and does not expect any further messages One special case, though: - if no ACK is received (only NAK's), and client runs out of revs to send, "done" is sent, and server sends just one more "NAK" A smarter scheme, which actually has a chance to detect more than one common rev, would be to send more than just one ACK. This patch implements the server side of the following extension to the protocol: - client sends at least one "want" message with "multi_ack" appended, like "want 1234567890123456789012345678901234567890 multi_ack" - if the server understands that extension, it will send ACK messages for all revs it has, not just the first one - server appends "continue" to the ACK messages like "ACK 1234567890123456789012345678901234567890 continue" until it has MAX_HAS-1 revs. In this manner, client knows when to stop sending revs by checking for the substring "continue" (and further knows that server understands multi_ack) In this manner, the protocol stays backwards compatible, since both client must send "want ... multi_ack" and server must answer with "ACK ... continue" to enable the extension. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

git-upload-pack: More efficient usage of the has_sha1 array

2005-10-24T22:13:36Z

This patch is based on Junio's proposal. It marks parents of common revs so that they do not clutter up the has_sha1 array. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano