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

On Thu, 12 Feb 2009, Jay Soffian wrote:

On Thu, Feb 12, 2009 at 3:27 PM, Daniel Barkalow [off-list ref] wrote:

quoted

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.

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.

quoted

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.

quoted

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.

quoted

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*