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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 11, 2019, 18:55 UTC
Message-ID: <xmqq7e8os8oi.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190711122452.GC65621@book.hvoigt.net>

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 7 quoted lines

>      if {$revs eq {}} {
>         set revs HEAD
> -    } elseif {[lsearch -exact $revs --all] >= 0} {
> -       lappend revs HEAD
> +    } else {
> +       linsert revs 0 --all-include-head
>      }

OK. So the new option means "from here on, the meaning of the '--all' option changes its meaning from 'all refs' to 'all refs and HEAD'". That way, gitk does not have to guess if '--all' found on the command line is an option or something else (e.g. pathspec etc.)

That makes sense. It would be a no-op if '--all' is not used, which is also good.

Show 12 quoted lines

>> To put it the other way around, what use case would we have that we
>> want to enumerate all refs but not HEAD, *and* exclude HEAD only
>> when HEAD is detached?  I can see the use of "what are commits
>> reachable from the current HEAD but not reachable from any of the
>> refs/*?" and that would be useful whether HEAD is detached or is on
>> a concrete branch, so "rev-parse --all" that does not include
>> detached HEAD alone does not feel so useful at least to me.
>
> What about my example. My use case is: Show me everything that is not merged
> into a stable branch (i.e. origin/master). For a human viewer it does not
> really matter if an extra detachted HEAD is shown, but for a CI script it
> might. Ok this might be quite artificial, what do you think?

That is, to drive "gitk --all ^origin/master"? If HEAD is detached, isn't the history that leads to it something that is "not merged into a stable branch", too? IOW, I think you would want the same behaviour as "git log --all ^origin/master" for that use case, and treat HEAD just like any of the refs.

Back in the days, detached HEAD was mostly tentative state, but these days, especially for those who use submodules, wouldn't it be a norm to have your checkout associated with a detached HEAD? I think treating (detached) HEAD just like any of the refs matches the end-user expectations even more these days.

Show 8 quoted lines

>> I am reasonably sure that back when "rev-parse --all" was invented,
>> the use of detached HEAD was not all that prevalent (I would not be
>> surprised if it hadn't been invented yet), so it being documented to
>> enumerate all refs does not necessarily contradict to include HEAD
>> if it is different from any of the ref tips (i.e. detached).
>
> I just dug up the old discussion to this to find some reasoning why this was
> not changed. So you have changed your mind about this? [1]

Yup.  See above.  I think the time has changed the needs.

Thanks.