Re: [PATCH 2/3] builtin-remote: teach show to display remote HEAD

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 12, 2009, 22:55 UTC
Message-ID: <alpine.LNX.1.00.0902121656570.19665@iabervon.org>
In-Reply-To: <76718490902121337l4b7f6f1dh25e6daa9adb48160@mail.gmail.com>

On Thu, 12 Feb 2009, Jay Soffian wrote:

Show 9 quoted lines

> On Thu, Feb 12, 2009 at 3:27 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >
> > struct ref *head = locate_head(refs, refs, NULL);
> > return head ? xstrdup(abbrev_branch(head->name)) : NULL;
> >
> > ?
> 
> No, I don't _think_ so. refs is everything from the remote side (tags,
> etc). I want to only match those things under refs/heads.

I was looking at your code and comparing with locate_head; it looks to me like you're using "ref" for both of the lists of refs that locate_head() gets. I think, actually, that checking for refs/heads in locate_head() would be a reasonable thing in general, and might avoid getting surprising results in clone with --mirror and odd refs or such.

Show 12 quoted lines

> I think I have to do something like this (this is more or less what
> builtin-clone does):
> 
> struct ref *remote_refs, *mapped_refs = NULL;
> struct refspec branch_refspec;
> 
> branch_refspec.force = 0;
> branch_refspec.src = branch_refspec.dst = "refs/heads";
> 
> remote_refs = transport_get_remote_refs(transport);
> get_fetch_map(remote_refs, branch_refspec, &mapped_refs, 0);
> head_points_at = locate_head(refs, mapped_refs, NULL);

You should be able to filter the ref list you already have, rather than refetching, if nothing else.

> > I'd somehow thought I'd moved locate_head() somewhere common, but it
> > really ought to be done.
> 
> I plan to move it into remote.c.

Good.

Show 7 quoted lines

> > There were periodic discussions of how you find
> > out when the remote repo changes its HEAD and you might want to do
> > something locally about it, and we never came up with a specific thing
> > for git to do, but the facility is probably useful.
> 
> Thus "git remote set-head -a" is the best I could come up with for
> setting it to what the remote has.

Yeah, that seems like a good interface.

Show 6 quoted lines

> > I have the vague memory, as well, that there's some way for a transport to
> > report that it actually knows that HEAD is a symref to something in
> > particular, and so git shouldn't guess.
> 
> I think for http://, but not for git://, but I'm *far* from an expert
> in this area.

Yes, it was information only available for http, but there's no reason to assume that other protocols couldn't provide it, and Junio mentioned a series from December (maybe never applied) to get the same info for the native git protocol.

	-Daniel
*This .sig left intentionally blank*