Re: [PATCH 2/3] refs: do not label special refs as pseudo refs

> >> > Are there any practical implications of the changes in this patch for users
> >> > running commands like "git log FETCH_HEAD" (I can't think of any off the top
> >> > of my head but it would be good to have some reassurance on that point in
> >> > the commit message)
> >>
> >> Not really, no. We have never been doing a good job at enforcing the
> >> difference between pseudo refs or normal refs anyway. Pseudo refs can be
> >> symrefs just fine, and our tooling won't complain. The only exception
> >> where I want us to become stricter is in how we enforce the syntax rules
> >> for root refs (which is handled by Peff in a separate patch series), and
> >> that we start to not treat FETCH_HEAD and MERGE_HEAD as proper refs.
> >> They should still resolve when you ask git-rev-parse(1), but when you
> >> iterate through refs they should not be surfaced as they _aren't_ refs.
> >
> > I actually would not even mind if they are surfaced when iterating with
> > --include-root-refs. But then I am a little skeptical of the purpose of
> > that feature in the first place. After all, the reason code shoves stuff
> > into .git/FOO_HEAD is precisely because we don't want other stuff
> > iterating over them, using them for reachability, and so on. That is why
> > "--all" does not include them, for example.
> >
> > But I did not follow the development of the feature, so maybe I am
> > missing some cool use case.
> >
> 
> The use case was to allow us to look at these refs when working with
> the reftable backend. Currently there is no way to do that, with the
> files backend, well you could just read the files. So mostly a debugging
> usecase.