Re: [PATCH] builtin-remote: better handling of multiple remote HEADs
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Feb 14, 2009, 20:21 UTC
- Message-ID
- <alpine.LNX.1.00.0902141503230.19665@iabervon.org>
- In-Reply-To
- <20090214175420.GA3457@coredump.intra.peff.net>
On Sat, 14 Feb 2009, Jeff King wrote:
Show 17 quoted lines
> 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*