On Fri, Aug 05 2022, Derrick Stolee wrote: > On 8/5/2022 10:50 AM, Ævar Arnfjörð Bjarmason wrote: >> >> On Fri, Aug 05 2022, Derrick Stolee wrote: > >>> 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? > > The possible slots are: > > * branch (refs/heads/) > * remoteBranch (refs/remotes/) > * tag (refs/tags/) > * stash (refs/stash) > * HEAD (HEAD) > * grafted (refs/replace/ or GIT_REPLACE_REF_BASE) > > These are exactly the namespaces that are now shown by default in > this series. No, e.g. "tag" doesn't mean "refs/tags/*", it means *a tag object*. Try this on master: git update-ref refs/archived-tags/v2.36.0 refs/tags/v2.36.0 Then on master: ./git -P -c color.decorate.tag="bold blue" log --oneline -1 v2.36.0 6cd33dceed6 (tag: v2.36.0, gitster/yw/cmake-use-pcre2, gitgitgadget/yw/cmake-use-pcre2, tag: refs/archived-tags/v2.36.0) Git 2.36 But on "seen" currently: $ ./git -P -c color.decorate.tag="bold blue" log --oneline -1 v2.36.0 6cd33dceed6 (tag: v2.36.0, gitster/yw/cmake-use-pcre2, gitgitgadget/yw/cmake-use-pcre2) Git 2.36 Before that "bold blue" applied to *tag objects*, but your series has made it apply to the refs/tags/* namespace. I noted this (indirectly) before in https://lore.kernel.org/git/220726.86tu73ncf8.gmgdl@xxxxxxxxxxxxxxxxxxx/; I.e. that I have a "refs/built-tags/" namespace. So that specifically seems like a regression by the criteria you've established for inclusion. I.e. we have objects that are impacted by existing coloring config now that your series is hiding, seemingly because you've conflated "tag object" with "a name in in refs/tags/". I *also* think it's overzelous to hide *uknown* things by default because we think we might add more *known* internal things in the future, but that's a distinct topic from this more narrow case, which seems to be a clear regression by criteria you're establishing & advocating for. > If someone adds a new color slot, then that would need to be > justified with a reason why that slot is important. We've already > had discussions as to why showing a decoration for notes is not > valuable to an end user. The stability of this config option (the > last addition of 'grafted' was in 2011) is good evidence that this > core set of namespaces is all users will need. > > By contrast, the use of "hidden" namespaces is relatively new and > is expected to increase in the near future. I really don't see how you're making the leap that because nobody's bothered to customize the coloring for things in custom namespaces that it's OK to hide them entirely. I just leave everything at the default color settings, aside from (after checking my ~/.gitconfig) one bit of diff coloring default that I found annoying.
