All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Todoroski <grnch_lists@gmx.net>
To: Jeff King <peff@peff.net>
Cc: Shawn Pearce <spearce@spearce.org>,
	Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	Jakub Narebski <jnareb@gmail.com>,
	git@vger.kernel.org
Subject: Re: Clone fails on a repo with too many heads/tags
Date: Sat, 24 Mar 2012 21:49:55 +0100	[thread overview]
Message-ID: <4F6E3373.7090500@gmx.net> (raw)
In-Reply-To: <20120321201722.GA15021@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On 21.03.2012 21:17, Jeff King wrote:
> On Wed, Mar 21, 2012 at 09:02:13PM +0100, Ivan Todoroski wrote:
> 
>>> Something in me feels slightly uncomfortable with that, just because
>>> simple newline-delimited formats make it easy for people to hack on the
>>> tool and feed input from unexpected sources.
>> I understand what you mean. How about this:
>>
>> If both --stdin and --stateless-rpc are specified to fetch-pack, it
>> will use pkt-line to read the refs from stdin before handing off
>> stdin to get_remote_heads().
>>
>> However, if only --stdin is specified, it will read refs from stdin
>> in a script-friendly newline delimited format, one ref per line. This
>> is okay because when --stateless-rpc is not specified
>> get_remote_heads() reads from an fd different from stdin so there is
>> no issue with residual buffers in this case.
>>
>> This way you preserve scriptability for any other callers who don't
>> use --stateless-rpc.
>>
>> How does this sound?
> 
> I think that sounds quite reasonable, and shouldn't be more than a few
> extra lines to implement.
> 
> -Peff


I wrote the code for this and went to write the test cases, but the test 
suite is not cooperating. :(

I'll send just the code changes for comments while I'm figuring out the 
test suite. I'll include the test cases along with better commit 
messages in the next version of the patches.

So, back to the test suite problem. To get familiar with it I first ran 
the test suite against the vanilla "maint" branch without any of my 
changes, just to see what I should expect on properly running code.

Unfortunately it failed, and to make matters worse it failed exactly on 
the parts dealing with smart HTTP, which is what I need to test in the 
first place. Talk about Murphy's law...

Is it failing for anyone else on the vanilla "maint" branch? I would 
appreciate any help I could get here.

My machine is CentOS 5.8 with latest updates and I have the httpd 
package installed. Here is the command that is failing (you can find the 
full output in the attachment):


$ GIT_TEST_HTTPD=yes ./t5551-http-fetch.sh -i -v
[... skip successful tests ...]
ok 5 - used upload-pack service

expecting success:
         git clone $HTTPD_URL/smart-redir-perm/repo.git --quiet repo-p

error: RPC failed; result=22, HTTP code = 405
fatal: The remote end hung up unexpectedly
not ok - 6 follow redirects (301)
#
#               git clone $HTTPD_URL/smart-redir-perm/repo.git --quiet 
repo-p
#


[-- Attachment #2: http-fetch.log --]
[-- Type: text/plain, Size: 2412 bytes --]

Initialized empty Git repository in /home/itodoroski/git/t/trash directory.t5551-http-fetch/.git/
expecting success: 
	echo content >file &&
	git add file &&
	git commit -m one

[master (root-commit) ba36540] one
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+)
 create mode 100644 file
ok 1 - setup repository

expecting success: 
	mkdir "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
	(cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
	 git --bare init
	) &&
	git remote add public "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
	git push public master:master

Initialized empty Git repository in /home/itodoroski/git/t/trash directory.t5551-http-fetch/httpd/www/repo.git/
To /home/itodoroski/git/t/trash directory.t5551-http-fetch/httpd/www/repo.git
 * [new branch]      master -> master
ok 2 - create http-accessible bare repository

expecting success: 
	GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
	test_cmp file clone/file &&
	tr '\015' Q <err |
	sed -e "
		s/Q\$//
		/^[*] /d
		/^$/d
		/^< $/d

		/^[^><]/{
			s/^/> /
		}

		/^> User-Agent: /d
		/^> Host: /d
		/^> POST /,$ {
			/^> Accept: [*]\\/[*]/d
		}
		s/^> Content-Length: .*/> Content-Length: xxx/
		/^> 00..want /d
		/^> 00.*done/d

		/^< Server: /d
		/^< Expires: /d
		/^< Date: /d
		/^< Content-Length: /d
		/^< Transfer-Encoding: /d
	" >act &&
	test_cmp exp act

ok 3 - clone http repository

expecting success: 
	echo content >>file &&
	git commit -a -m two &&
	git push public
	(cd clone && git pull) &&
	test_cmp file clone/file

[master ace4881] two
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+)
To /home/itodoroski/git/t/trash directory.t5551-http-fetch/httpd/www/repo.git
   ba36540..ace4881  master -> master
From http://127.0.0.1:5551/smart/repo
   ba36540..ace4881  master     -> origin/master
Updating ba36540..ace4881
Fast-forward
 file |    1 +
 1 file changed, 1 insertion(+)
ok 4 - fetch changes via http

expecting success: 
	sed -e "
		s/^.* \"//
		s/\"//
		s/ [1-9][0-9]*\$//
		s/^GET /GET  /
	" >act <"$HTTPD_ROOT_PATH"/access.log &&
	test_cmp exp act

ok 5 - used upload-pack service

expecting success: 
	git clone $HTTPD_URL/smart-redir-perm/repo.git --quiet repo-p

error: RPC failed; result=22, HTTP code = 405
fatal: The remote end hung up unexpectedly
not ok - 6 follow redirects (301)
#	
#		git clone $HTTPD_URL/smart-redir-perm/repo.git --quiet repo-p
#	

  reply	other threads:[~2012-03-24 20:50 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-18  8:14 Clone fails on a repo with too many heads/tags Ivan Todoroski
2012-03-18 11:37 ` Ivan Todoroski
2012-03-18 12:04   ` Nguyen Thai Ngoc Duy
2012-03-18 16:36 ` Jakub Narebski
2012-03-18 19:07   ` Jeff King
2012-03-18 22:07     ` Jakub Narebski
2012-03-19  2:32       ` Jeff King
2012-03-19  2:43         ` Nguyen Thai Ngoc Duy
2012-03-19  2:45           ` Jeff King
2012-03-19  1:05     ` Ivan Todoroski
2012-03-19  1:30     ` Nguyen Thai Ngoc Duy
2012-03-19  2:44       ` Jeff King
2012-03-21 11:05         ` Ivan Todoroski
2012-03-21 14:28           ` Shawn Pearce
2012-03-21 17:14             ` Jeff King
2012-03-21 17:59               ` Jakub Narebski
2012-03-21 20:02               ` Ivan Todoroski
2012-03-21 20:17                 ` Jeff King
2012-03-24 20:49                   ` Ivan Todoroski [this message]
2012-03-25  1:06                     ` Jeff King
2012-03-25  2:32                       ` Jeff King
2012-03-25 17:33                         ` Ivan Todoroski
2012-03-25 17:54                           ` Ivan Todoroski
2012-03-26 17:33                             ` Jeff King
2012-03-27  7:07                               ` Ivan Todoroski
2012-03-25 15:30                       ` Ivan Todoroski
2012-03-24 20:53                   ` [PATCH/RFC 1/2] fetch-pack: new option to read refs from stdin Ivan Todoroski
2012-03-25  1:19                     ` Jeff King
2012-03-25  9:39                       ` Ivan Todoroski
2012-03-25 15:15                         ` Ivan Todoroski
2012-03-25 20:00                       ` Ivan Todoroski
2012-03-26 17:21                         ` Jeff King
2012-03-26 17:49                           ` Ivan Todoroski
2012-03-26 17:51                             ` Jeff King
2012-03-24 20:54                   ` [PATCH/RFC 2/2] remote-curl: send the refs to fetch-pack on stdin Ivan Todoroski
2012-03-25  1:24                     ` Jeff King
2012-03-25  9:52                       ` Ivan Todoroski
2012-03-26 17:24                         ` Jeff King
2012-03-27  6:23               ` [PATCH/RFC v2 0/4] Fix fetch-pack command line overflow during clone Ivan Todoroski
2012-03-27  6:25                 ` [PATCH/RFC v2 1/4] fetch-pack: new --stdin option to read refs from stdin Ivan Todoroski
2012-03-27 16:59                   ` Junio C Hamano
2012-03-27 23:18                     ` Ivan Todoroski
2012-03-27 23:26                       ` Junio C Hamano
2012-03-27 23:48                         ` Ivan Todoroski
2012-03-27  6:26                 ` [PATCH/RFC v2 2/4] remote-curl: send the refs to fetch-pack on stdin Ivan Todoroski
2012-03-27 17:18                   ` Junio C Hamano
2012-03-27 23:20                     ` Ivan Todoroski
2012-03-27  6:27                 ` [PATCH/RFC v2 3/4] fetch-pack: test cases for the new --stdin option Ivan Todoroski
2012-03-27 17:40                   ` Junio C Hamano
2012-03-27 23:36                     ` Ivan Todoroski
2012-03-27 23:43                       ` Junio C Hamano
2012-03-28  0:14                       ` Ivan Todoroski
2012-03-27  6:28                 ` [PATCH/RFC v2 4/4] remote-curl: main test case for the OS command line overflow Ivan Todoroski
2012-03-27 17:43                   ` Junio C Hamano

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=4F6E3373.7090500@gmx.net \
    --to=grnch_lists@gmx.net \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.