From: Daniel Barkalow <barkalow@iabervon.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: John Wiegley <johnw@newartisans.com>, git@vger.kernel.org
Subject: Re: Problem with git fetch over http://
Date: Fri, 25 Apr 2008 19:35:45 -0400 (EDT) [thread overview]
Message-ID: <alpine.LNX.1.00.0804251842510.19665@iabervon.org> (raw)
In-Reply-To: <7vskx9o9ek.fsf@gitster.siamese.dyndns.org>
On Fri, 25 Apr 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > John mentioned on IRC that clone works.
> >
> > $ git-ls-remote http://newartisans.com/git/ledger.git
> > 96751442d9eda537480867e599e4c604663f4530 refs/heads/master
> > 365baca5174232cc35e4ed190fd8ce93c3611c84 refs/heads/v2.4.1
> > f972a89073843fdbb2a1bef969d9ca70509d4bfe refs/heads/v2.5
> > 6a81d760dc4ab9028b27430124702c28c0b894ed refs/tags/cvs-20040410
> > fed3956a310a2ea8c8595b7fde7aaa0623492ca6 refs/tags/v0.1
> > ...
> >
> > $ git-ls-remote git://newartisans.com/ledger.git
> > 96751442d9eda537480867e599e4c604663f4530 HEAD
> > 96751442d9eda537480867e599e4c604663f4530 refs/heads/master
> > 365baca5174232cc35e4ed190fd8ce93c3611c84 refs/heads/v2.4.1
> > f972a89073843fdbb2a1bef969d9ca70509d4bfe refs/heads/v2.5
> > 6a81d760dc4ab9028b27430124702c28c0b894ed refs/tags/cvs-20040410
> > fed3956a310a2ea8c8595b7fde7aaa0623492ca6 refs/tags/v0.1
> > ...
> >
> > Looks like either server-info.c:update_info_refs() needs to also list
> > HEAD, or transport.c:get_refs_via_curl() needs to guess that $url/HEAD
> > exists and fetch it to add to the list, or both.
>
> Wait a minute. How did "git fetch http://host/repo.git" work before C
> rewrite?
>
> The reason I ask is because info/refs traditionally did not list HEAD and
> fetch either would have failed to start walking from HEAD (iow, the issue
> was very old), or it didn't care (iow, the issue is a regression after C
> rewrite).
I never managed to trace through the shell fetch code, but I suspect that
it broke quite a long time ago (git-ls-remote.sh didn't list HEAD for
http:// URLs, anyway). clone works because it uses entirely different
code, and "git fetch origin" (when origin is an http URL) works, and "git
fetch http://... branch" works (and is a workaround), and that's probably
all that people use regularly. This only comes up because there's an
automated fetch-and-build system that uses "<vcs> command <location>" to
update, and it needed an actual quirk, rather than people just training
their fingers to do things that work.
-Daniel
*This .sig left intentionally blank*
prev parent reply other threads:[~2008-04-25 23:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-25 20:42 Problem with git fetch over http:// John Wiegley
2008-04-25 21:24 ` Junio C Hamano
2008-04-25 21:34 ` Mike Hommey
2008-04-25 22:04 ` Daniel Barkalow
2008-04-25 22:29 ` Junio C Hamano
2008-04-25 23:35 ` Daniel Barkalow [this message]
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=alpine.LNX.1.00.0804251842510.19665@iabervon.org \
--to=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johnw@newartisans.com \
/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