Re: [PATCH] gitk: fix --all behavior combined with --not

[Johannes Sixt <j6t@kdbg.org>]

Am 10.07.19 um 20:40 schrieb Junio C Hamano:
> Heiko Voigt <hvoigt@hvoigt.net> 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