Re: [PATCH v1 4/6] Expanded branch header for Porcelain Status V2

From: Jeff Hostetler <git@jeffhostetler.com>
To: Jeff King <peff@peff.net>, Jeff Hostetler <jeffhost@microsoft.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v1 4/6] Expanded branch header for Porcelain Status V2
Date: Wed, 20 Jul 2016 14:20:24 -0400	[thread overview]
Message-ID: <578FC0E8.4010102@jeffhostetler.com> (raw)
In-Reply-To: <20160720160635.GC24902@sigill.intra.peff.net>

On 07/20/2016 12:06 PM, Jeff King wrote:
> On Tue, Jul 19, 2016 at 06:10:56PM -0400, Jeff Hostetler wrote:
>
>> +	} else {
>> +		/*
>> +		 * TODO All of various print routines allow for s->branch to be null.
>> +		 * TODO When can this happen and what should we report here?
>> +		 */
>> +		fprintf(s->fp, " %s", "(unknown)");
>> +	}
>
> IIRC, it happens when HEAD points to a broken ref. So something like:
>
>    git init
>    echo broken >.git/refs/heads/master
>
> would cause resolving HEAD to return NULL.

That worked and I see "(unknown)".

This is a bit of a nit, but is there a value we'd like
to see there, such as "(unknown)" or "(broken)" or "(missing)"
in that case?  (And make it clear that this is a different
case from "(detached)".)

I'm thinking it would be nicer to always have a field
there for parsing.

Jeff