Junio C Hamano <gitster@xxxxxxxxx> writes:
>
> It would not begin with 40-hex, though. If I were doing this,
> perhaps I'd say we should first split is_pseudoref_syntax() that is
> overly loose into to classes (e.g. "caps with underscores that ends
> with HEAD" and everything else), silently reject false positives
> among the latter class. Then we rename those that are misnamed
> (there should be only few, like AUTO_MERGE that should be a
> pseudoref but named without _HEAD; I do not think of anything that
> ends with _HEAD that is not a ref) over time and drop the latter
> class.
>
I agree about checking the contents of the files to filter out false
positives around the filenames. Alright, this seems like a good way to
go.
Summarizing, we'll change `is_pseudoref_syntax()` to
1. Check for filename to be UPPERCASE including '-', '_'.
a. If the filename ends with _HEAD, we return as positive
b. Else check the file content for SHA1/SHA256 hex
This still leaves out HEAD ref, which is not a pseudo ref (since it can
be a symref at times). I'll figure out something there.
>
>> While you're here, I wonder if you have any thoughts on the last block
>> of my first mail.
>>
>>> Over this, I'm also curious on what the mailing list thinks about
>>> exposing this to the client side. Would an `--all` option for
>>> git-for-each-ref(1) be sufficient?
>
> "list pseudorefs in addition to things below refs/"? Sounds OK to
> me as a feature.
>
> However, "--all" does not mean that in the context of "git log"
> family of commands. Over there, it means "not just --branches,
> --tags, and --remotes, but everything" which is still limited below
> "refs/".
>
Good point, I agree, usage of "--all" would clash here.
> As "git for-each-ref" takes pattern that is prefix match, e.g.,
>
> $ git for-each-ref refs/remotes/
>
> shows everything like refs/remotes/origin/main that begins with
> refs/remotes/, I wonder if
>
> $ git for-each-ref ""
>
> should mean what you are asking for. After all, "git for-each-ref"
> does *not* take "--branches" and others like "git log" family to
> limit its operation to subhierarchy of "refs/" to begin with.
But I don't think using an empty pattern is the best way to go forward.
This would break the pattern matching feature. For instance, what if the
user wanted to print all refs, but pattern match "*_HEAD"?
Would that be
$ git for-each-ref "" "*_HEAD"
I think this would be confusing, since the first pattern is now acting
as an option, since its not really filtering rather its changing the
search space.
Maybe "--all-refs" or "--all-ref-types" instead?
Attachment:
signature.asc
Description: PGP signature
