{"thread":{"id":"34749","subject":"[BUGLET] git bisect visualize does not show BISECT_HEAD","startedAt":"2013-08-23T13:21:27Z","lastAt":"2013-08-23T13:21:27Z","messageCount":1,"participants":["Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"225718","messageId":"20130823152127.73733364@chalon.bertin.fr","threadId":"34749","inReplyTo":null,"subject":"[BUGLET] git bisect visualize does not show BISECT_HEAD","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2013-08-23T13:21:27Z","receivedAt":"2013-08-23T13:21:27Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"[v1.8.3.4]\n\n\"git bisect visualize\" when run without --no-checkout has the standard gitk handling of\n\"HEAD\" showing what the current revision being tested is (as a yellow node).\n\nNow when using --no-checkout, the information \"current revision\" we may be looking for\nhas nothing to do with HEAD any longer: we need BISECT_HEAD instead - and if by any chance\nHEAD would happen to be in the displayed scope, the user may do wrong assumptions about\nit (maybe).\n\n\nWondering whether there would be any flags that would pass to gitk through \"bisect visualize\",\nI naively tried:\n\n $ git bisect visualize -h\n usage: git log [<options>] [<revision range>] [[--] <path>...]\n   or: git show [options] <object>...\n\n    --quiet               suppress diff output\n    --source              show source\n    --use-mailmap         Use mail map file\n    --decorate[=...]      decorate options\n    -L <n,m:file>         Process line range n,m in file, counting from 1\n\nWandering away from what I was look for:\n\n $ git bisect visualize --decorate\n ... some git log output\n\nThat seems unfortunate in its own right as well...\n\n\nBack to the problem of visualizing the info, it looks like gitk would need a way to display\nrefs that are not displayed by default, when we need them.  Something like:\n\n\tgitk --explicit-refs=BISECT_HEAD,refs/whatever\n\nThat would also be helpful when one tries to look at the reflog graphically: whereas\ngitk accepts to show whatever@{1} and friends, it never tells us which revision corresponds\nto which reflog entry, and --explicit-refs=whatever@{1},whatever@{2} would help here, as would\nsomething like --explicit-refs=whatever@{*} or --explicit-refs=whatever@{1..5}, but that starts\nto be more tricky to formalize.\n\nThoughts, anyone ?\n\n-- \nYann Dirson - Bertin Technologies\n"}]}