Am 10.07.19 um 20:40 schrieb Junio C Hamano: > Heiko Voigt <hvoigt@xxxxxxxxxx> writes: > >> behavior. How about '--all-include-head'. Then e.g. >> >> git rev-parse --all-include-head --all --not origin/master >> >> would include the head ref like you proposed below? >> >> What do you think? Or would you rather go the route of changing >> rev-parse behavior? > > Depends on what you mean by the above. Do you mean that now the end > user needs to say > > gitk --all-include-head --not origin/master > > to get a rough equivalent of > > git log --graph --oneline --all --not origin/master > > due to the discrepancy between how "rev-parse" and "rev-list" treat > their "--all" option? Or do you mean that the end user still says > "--all", and after (reliably by some means) making sure that "--all" > given by the end-user is a request for "all refs and HEAD", we turn > that into the above internal rev-parse call? > > If the former, then quite honestly, we shouldn't doing anything, > perhaps other than reverting 4d5e1b1319. The users can type > > $ gitk --all HEAD --not origin/master > $ gitk $commit --not --all HEAD > > themselves, instead of --all-include-head. When --all is in the game, HEAD of the current worktree isn't all that special among the heads of all worktrees, I would think. What if we added a new option --heads that incorporates all worktree heads? If we require users to type something to tell what they mean, then I think a more generally useful command line option would be preferable over an option that modifies the meaning of another option. -- Hannes
