From: Clemens Buchacher <drizzd@aon.at>
To: Tay Ray Chuan <rctay89@gmail.com>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH 4/7] t5540-http-push: expect success when pushing without arguments
Date: Sun, 25 Oct 2009 17:16:31 +0100 [thread overview]
Message-ID: <20091025161630.GB8532@localhost> (raw)
In-Reply-To: <20091025232142.6558d9e4.rctay89@gmail.com>
On Sun, Oct 25, 2009 at 11:21:42PM +0800, Tay Ray Chuan wrote:
> But after c6aa27e (Move WebDAV HTTP push under remote-curl, Wed Oct
> 14), the dumb http mechanism additionally learns about the refs through
> /info/refs (via remote-curl.c::get_refs), so it is aware of packed
> refs, even though it still doesn't read /packed-refs (assuming /info/
> refs is up-to-date). Thus the push now succeeds.
If left as is, it should actually fail, and for two reasons.
1. push aborts immediately because info/refs is not updated by "git
update-ref" so that it thinks everything is up-to-date from the previous
test. The old http-push code did not check for up-to-date refs which is why
this problem did not trigger so far. This is fixed in "update http tests
according to remote-curl capabilities".
2. Even if info/refs is updated, a bug in the new remote-helper causes push
to exit with error status 128. This is fixed in "remote-helpers: return
successfully if everything up-to-date".
This is unrelated to the original intention of the test, but I think it
doesn't hurt to keep it around, at least for the time being.
It's unfortunate that we both worked on t5540 at the same time. But except
for this point I think our changes are compatible.
Clemens
next prev parent reply other threads:[~2009-10-25 16:20 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 3:36 [RFC PATCH v3 00/17] Return of smart HTTP Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 01/17] pkt-line: Add strbuf based functions Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 02/17] pkt-line: Make packet_read_line easier to debug Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 03/17] fetch-pack: Use a strbuf to compose the want list Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 04/17] Move "get_ack()" back to fetch-pack Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 05/17] Add multi_ack_detailed capability to fetch-pack/upload-pack Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 06/17] remote-curl: Refactor walker initialization Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 07/17] fetch: Allow transport -v -v -v to set verbosity to 3 Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 08/17] remote-helpers: Fetch more than one ref in a batch Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 09/17] remote-helpers: Support custom transport options Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 10/17] Move WebDAV HTTP push under remote-curl Shawn O. Pearce
2009-10-19 2:59 ` Tay Ray Chuan
2009-10-28 1:08 ` Shawn O. Pearce
2009-10-28 11:01 ` Tay Ray Chuan
2009-10-25 15:19 ` [PATCH 2/7] http-push: allow stderr messages to appear alongside helper_status ones Tay Ray Chuan
2009-10-15 3:36 ` [RFC PATCH v3 11/17] Git-aware CGI to provide dumb HTTP transport Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 12/17] Add stateless RPC options to upload-pack, receive-pack Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 13/17] Smart fetch and push over HTTP: server side Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 14/17] Discover refs via smart HTTP server when available Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 15/17] Smart push over HTTP: client side Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 16/17] Smart fetch " Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 17/17] Smart HTTP fetch: gzip requests Shawn O. Pearce
2009-10-15 7:39 ` [RFC PATCH v3 00/17] Return of smart HTTP Junio C Hamano
2009-10-15 9:52 ` Nanako Shiraishi
2009-10-15 14:33 ` Shawn O. Pearce
2009-10-15 15:21 ` Johan Herland
2009-10-15 15:41 ` Shawn O. Pearce
2009-10-15 20:27 ` Junio C Hamano
2009-10-15 20:45 ` Shawn O. Pearce
2009-10-22 10:21 ` Nanako Shiraishi
2009-10-22 14:46 ` Daniel Barkalow
2009-10-27 4:55 ` [PATCH] Fix memory leak in transport-helper Daniel Barkalow
2009-10-27 14:11 ` Johannes Schindelin
2009-10-27 17:37 ` Daniel Barkalow
2009-10-27 18:31 ` Jeff King
2009-10-27 18:54 ` Johannes Schindelin
2009-10-27 19:05 ` Daniel Barkalow
2009-10-28 7:18 ` Junio C Hamano
2009-10-16 4:20 ` [RFC PATCH v3 00/17] Return of smart HTTP Mark Lodato
2009-10-16 14:31 ` Shawn O. Pearce
2009-10-16 23:04 ` Mark Lodato
2009-10-16 23:16 ` Shawn O. Pearce
2009-10-22 19:48 ` Marcus Camen
2009-10-25 15:16 ` [PATCH 0/6] http: push and test fixes Tay Ray Chuan
2009-10-25 15:18 ` [PATCH 1/7] http-push: fix check condition on http.c::finish_http_pack_request() Tay Ray Chuan
2009-10-25 15:20 ` [PATCH 3/7] http-push: add more 'error <dst> <why>' status reports Tay Ray Chuan
2009-10-25 15:21 ` [PATCH 4/7] t5540-http-push: expect success when pushing without arguments Tay Ray Chuan
2009-10-25 16:16 ` Clemens Buchacher [this message]
2009-10-25 15:22 ` [PATCH 5/7] t5540-http-push: check existence of fetched files Tay Ray Chuan
2009-10-25 16:49 ` Clemens Buchacher
2009-10-25 15:23 ` [PATCH 6/7] t5540-http-push: when deleting remote refs, don't need to branch -d -r Tay Ray Chuan
2009-10-25 15:24 ` [PATCH 7/7] t5540-http-push: remove redundant fetches Tay Ray Chuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091025161630.GB8532@localhost \
--to=drizzd@aon.at \
--cc=git@vger.kernel.org \
--cc=rctay89@gmail.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).