Re: [PATCH] Fix branches file configuration

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> 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.