Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
> It was an intentional omission because the refs/bisect/* references
> are not part of the color.decorate.<slot> category.
>
> Looking into it further, the bisect refs look pretty ugly (especially
> the ones like "refs/bisect/good-<hash>").
>
> If you would like to include these in the default filter, then I
> would recommend also adding a color.decorate.<slot> category for them
> and possibly replace the "refs/bisect" with just "bisect". Alternatively,
> you could take a hint from replace objects and just use an indicator
> like "bisect good" or "bisect bad" instead of listing the full ref name.
I personally do not think bisect/bad and bisect/good-* need to be
part of the default set of refs to use for decoration.
I suspect that the suggestion to use them for decoration is based on
the gut feeling: "People during their bisect session would want to
know which points they already examined and what their states are."
But during bisection, there is a specific command to give them
exactly that information: "bisect visualize". It is roughly
equilvalent to:
git log refs/bisect/bad \
$(git for-each-ref --format='^%(refname)' refs/bisect/good-\*
i.e. show the history surrounded by all the known-to-be-good commits
and the known-to-be-bad commit we currently are chasing. Bad and good
commits are at the boundary you can tell them without decoration.
But if we still want to see bisect/bad and bisect/good-* in a larger
graph (i.e. showing descendants of bad and ancestors of good), then
I do not think good-<object name> being a long label is something we
should special case and shorten. Especially because the user is not
using "bisect visualize", which is readable without decoration, they
may be seeking more information in the names, perhaps cutting and
pasting the object names to feed "git show" running on a separate
terminal, or something.
