Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > On Tue, 25 Mar 2008, Junio C Hamano wrote: > >> ... I am reasonably sure about "fetching from $URL/bar" >> part, but I am unsure about "store in foo/bar" part. >> >> Any Cogito survivers out there who knows how this was supposed to have >> worked? We can go back and look at git-fetch.sh (in contrib/examples), >> but I'd rather be lazy ;-) > > This code actually is from Linus, nearly 2 years ago, converting > git-push.sh; I then moved it from builtin-push.c to remote.c and later > added support to remote.c for the fetch side aspects while leaving that > part of the code alone. Of course, I didn't realize at any point that, as > a fetch configuration, a branches configuration ever stored things > anywhere, and it looks like it didn't with a slash. (See line 115 of > 755225de:git-parse-remote.sh) Yeah, it slowly comes back to me. I think the Penguin desire that triggered this mysterious syntax was something like defining: $ echo >.git/branches/garzik git://git.kernel.org/pub/scm/linux/kernel/jgarzik and being able to say: $ git fetch garzik/netdev-2.6 for-linus $ git fetch garzik/libata-dev master > So I guess there should be: > >> > add_url_alias(remote, p); >> > - add_fetch_refspec(remote, branch); > if (!slash) >> > + strbuf_addf(&branch, ":refs/heads/%s", remote->name); >> > + add_fetch_refspec(remote, strbuf_detach(&branch, 0)); >> > remote->fetch_tags = 1; /* always auto-follow */ >> > } Yeah, sounds like it. Will queue in 'next', for eventual inclusion in 'maint'. This is a 1.5.4 regression fix, together with "push --tags" fix we discussed today. -- 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
