On Wed, Jul 27 2022, Derrick Stolee wrote:
> On 7/26/22 2:19 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Tue, Jul 26 2022, Derrick Stolee wrote:
>>
>>> On 7/26/2022 10:44 AM, Ævar Arnfjörð Bjarmason wrote:
>
>>>> But I think this change is going about it the wrong way, let's have a
>>>> list of refs that Git knows about as magical, instead of assuming that
>>>> we can ignore everything that's not on a small list of things we're
>>>> including.
>>>>
>>>> Wouldn't that give you what you want, and not exclude these sorts of
>>>> custom refs unexpectedly for users?
>>>
>>> Instead of keeping track of an ever-growing list of exclusions, instead
>>> making a clear list of "this is what most users will want for their
>>> decorations" is a better approach.
>>>
>>> Users who know how to create custom refs outside of this space have the
>>> capability to figure out how to show their special refs. My general ideas
>>> for designing these kinds of features is to have a default that is focused
>>> on the typical user while giving config options for experts to tweak those
>>> defaults.
>>>
>>> You're right that this series perhaps leaves something to be desired in
>>> that second part, since there isn't an easy _config-based_ way to enable
>>> all decorations (or a small additional subset).
>>
>> Yes, but this is just side-stepping the issue. Your X-Y problem is that
>> you want to exclude certain refs that we're specifically creating.
>>
>> I think that's fair enough, but I don't see why we're not specifically
>> excluding just those then.
>
> I'm advocating that we make a one-time change to have a set of "known
> useful refs"
You can't know the set of known-useful refs. Unless we explicitly lay
claim to something in the namespace it's the user's.
This series seems to have started out by observing that "git log" is
showing certain "useless" refs added in another topic, since they're
owned by git, and "internal-only", which is fair enough.
But I don't see how we can or should make the leap to things that are
not on a limited "not-useless" list git knows about should be the only
thing we should display.
Wouldn't carrying a list of what to exclude achive the same goal (but
see below...).
> as showing up in the decorations. Perhaps some users (like yourself)
> need to react to that change, but it happens _once_.
It's long-established behavior, we try not to change that sort of
thing. In this case I think we *could*, i.e. I don't imagine it would be
a *huge* disruption if we had a good reason, e.g. the use-cases of
machine-parsing this are fairly obscure.
But the disruption seems unwarranted if it's just to hide the likes of
refs/bundle/, when we can just address those specifically.
And it's not "once", it's N times for each downstream user that'll run
into this, whereas not changing the behavior is effort among a small
group of git developers...
> Changing the rules repeatedly as new "hidden" namespaces are added is
> more likely to cause confusion multiple times.
I really don't see the worry about a maintenance burden of having a
thing in refs.c (or whatever) that's just:
hide_from_decorate[] = {
"refs/bundle/*"
[...],
NULL
};
Worst case we'll create another "magic" ref, forget to add to the list,
and someone will notice and we'll add it.
Which at that point will be a one-line change, and preferrable to N
users having to chase down some new config which explains why their
local refs aren't shown anymore with decorate...
