git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Heiko Voigt <hvoigt@hvoigt.net>
Cc: paulus@samba.org, max@max630.net, git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] gitk: fix --all behavior combined with --not
Date: Wed, 10 Jul 2019 11:40:50 -0700	[thread overview]
Message-ID: <xmqqa7dlu40d.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190710075835.GB65621@book.hvoigt.net> (Heiko Voigt's message of "Wed, 10 Jul 2019 09:58:35 +0200")

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.

If the latter, I am not sure what the endgame should be.  

It certainly *is* safer not to unconditionallyl and unilaterally
change the behaviour of "rev-parse --all", so I am all for starting
with small and fully backward compatible change, but wouldn't
scripts other than gitk want the same behaviour?  

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.

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).

And if we cannot commit to changing the "rev-parse --all" (and I am
not sure I can at this point---I am wary of changes), as we know
where "--all" appeared on the command line, inserting HEAD immediately
after it at the script level is probably the change with the least
potential damage we can make, without changing anything else.



>
> Cheers Heiko
>
>> 
>>  builtin/rev-parse.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
>> index f8bbe6d47e..94f9a6efba 100644
>> --- a/builtin/rev-parse.c
>> +++ b/builtin/rev-parse.c
>> @@ -766,6 +766,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
>>  			}
>>  			if (!strcmp(arg, "--all")) {
>>  				for_each_ref(show_reference, NULL);
>> +				head_ref(show_reference, NULL);
>>  				clear_ref_exclusion(&ref_excludes);
>>  				continue;
>>  			}

  reply	other threads:[~2019-07-10 18:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04  8:09 [PATCH] gitk: fix --all behavior combined with --not Heiko Voigt
2019-07-04 10:38 ` Johannes Schindelin
2019-07-04 11:31   ` Heiko Voigt
2019-07-08 19:01 ` Junio C Hamano
2019-07-09  4:55   ` Junio C Hamano
2019-07-09  5:16     ` Junio C Hamano
2019-07-10  7:58       ` Heiko Voigt
2019-07-10 18:40         ` Junio C Hamano [this message]
2019-07-11 12:24           ` Heiko Voigt
2019-07-11 18:55             ` Junio C Hamano
2019-07-11 17:11           ` Johannes Sixt
2019-07-10  7:44     ` Heiko Voigt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqa7dlu40d.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    --cc=max@max630.net \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).