On Sat, 14 Feb 2009, Jeff King wrote:
> On Sat, Feb 14, 2009 at 05:30:30AM -0500, Jay Soffian wrote:
>
> > + else if (states.heads.nr == 1)
> > + printf(" HEAD branch: %s\n",
> > + states.heads.items[0].string);
> > + else
> > + show_list(" HEAD branch%s:", &states.heads, "");
>
> I was happy to see the common case of "we unambiguously determined HEAD"
> falls back to nicer output (though I admit I did a double-take seeing
> both show_list and the states.heads.nr check, I see it is because
> show_list always insists on a newline).
>
> That should help current users with simple setups, but also support
> unambiguous HEAD reporting in the future (and based on what Daniel said
> earlier, http should just need a client patch to pass the information
> up the callstack).
I haven't checked lately, but I think that what's actually needed is to
have the locate_head() function notice if the struct ref for HEAD actually
has the symref field non-NULL, and report that as the unambiguous answer.
This should also allow it to automatically pick up any other
disambiguation by future sources of lists of refs that include HEAD,
whether that's git protocol extensions, filesystem access to the repo, or
foreign VCSes where some branches is inherently primary, or whatever.
(The direct purpose of collecting the information for http was so that it
could figure out the sha1 at all for the remote HEAD when it's a symref;
the code just doesn't then explicitly throw the information away.)
-Daniel
*This .sig left intentionally blank*
--
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
