On Fri, Aug 05 2022, Derrick Stolee wrote:

On 8/5/2022 10:50 AM, Ævar Arnfjörð Bjarmason wrote:

quoted

On Fri, Aug 05 2022, Derrick Stolee wrote:

quoted

quoted

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@evledraar.gmail.com/ (local);
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.