Junio C Hamano <gitster@xxxxxxxxx> writes: > 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 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. Thanks, both. I think "bisect visualize" covers the use case I was thinking of (seeing the bisect result in the commit history), so omitting refs/bisect/* sounds fine. And if users are unhappy about the change, it seems simple enough to add it to the list.
