On Fri, Aug 05 2022, Derrick Stolee wrote: > On 8/4/2022 3:08 AM, Ævar Arnfjörð Bjarmason wrote: > >> There's no lack of "stability", because the ref hiding only act on >> what's known to be something we can ignore, because our git version >> knows about it. >> >> If git v2.40 knows about refs/magical-1/* but not refs/magical-2/*, but >> git v2.50 knows about both it's not a lack of stability that v2.40 shows >> one decorated by default, but v2.50 shows neither. > > You are describing how the behavior changes between these versions on > the same repository. That's what I mean by lack of stability. If you want that forward-stability wouldn't another way to accomplish this to put all of these new magical refs in the same refs/git-internal/ namespace, e.g. refs/git-internal/foo/, refs/git-internal/bar/? >> But it's not just that I disagree, I genuinely don't get your POV >> here. > > I'm optimizing for non-experts who never need any refs outside of the > standard set. Clearly, I'm wondering if we can find a way forward that doesn't change existing long-statnding behavior and caters to the "stability" of future inter-version behavior with this new class of refs. > Now that this version removed the notes ref from the > decoration, the stance for inclusion is simple: > > If Git offers to color the namespace with color.decoration.<slot>, > then Git decorates with that namespace by default. I'm a bit confused, sorry. So aside from "notes", if we have a color.decoration.<slot> applying to a ref now, it's a bug in your series if it's not showing up anymore? I still find that inclusion criteria to be a bit odd, we've usually considered colors optional sugar. Just because nobody bothered to add a coloring config for it doesn't seem like a good reason to not show something at all.
