From: Jeff Hostetler Date: Thu, 21 Jul 2016 19:03:01 GMT Subject: Re: [PATCH v1 4/6] Expanded branch header for Porcelain Status V2 Message-ID: <57911C65.2050601@jeffhostetler.com> In-Reply-To: On 07/21/2016 11:46 AM, Johannes Schindelin wrote: > On Wed, 20 Jul 2016, Jeff King wrote: > >> On Wed, Jul 20, 2016 at 02:20:24PM -0400, Jeff Hostetler wrote: >> >>>> 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. >> >> My gut feeling is to err on the side of being vague, like "unknown". >> This is something that _shouldn't_ ever happen, and if it does, it could >> be a broken on-disk ref, a transient syscall error, or some other >> weirdness. I don't think we need to get too specific in this context >> (we'll likely have said something else useful on stderr already, I >> think). > > FWIW I think "unknown" is a nice conservative way to shrug Git's > shoulders. > > When we call `git status --porcelain=v2` and read "unknown", we could > always try to find out more using additional low-level tools and/or disk > access: this is such a rare case that it does not *really* matter all that > much. yes, this case causes even rev-parse fits. I'l make it return a known quantity so that users don't have to deal with stuff like: $ more .git/HEAD ref: refs/heads/foo $ more .git/refs/heads/foo brokwn $ git rev-parse HEAD HEAD fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' $ git rev-parse HEAD -- fatal: bad revision 'HEAD' $ Jeff