* [PATCH] gitk: fix --all behavior combined with --not @ 2019-07-04 8:09 Heiko Voigt 2019-07-04 10:38 ` Johannes Schindelin 2019-07-08 19:01 ` Junio C Hamano 0 siblings, 2 replies; 12+ messages in thread From: Heiko Voigt @ 2019-07-04 8:09 UTC (permalink / raw) To: paulus, max; +Cc: git In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified", 2014-09-09) the intention was to have detached HEAD shown when the --all argument is given. This was solved by appending HEAD to the revs list. By doing that the behavior using the --not argument is now broken, since that inverts the meaning of all following arguments passed to git rev-parse. Lets fix this by prepending HEAD instead of appending, this way there can not be any '--not' in front. This was discovered because gitk --all --not origin/master does not display the same revs as gitk --all ^origin/master which it should. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> --- gitk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitk b/gitk index a14d7a1..19d95cd 100755 --- a/gitk +++ b/gitk @@ -295,7 +295,7 @@ proc parseviewrevs {view revs} { if {$revs eq {}} { set revs HEAD } elseif {[lsearch -exact $revs --all] >= 0} { - lappend revs HEAD + linsert revs 0 HEAD } if {[catch {set ids [eval exec git rev-parse $revs]} err]} { # we get stdout followed by stderr in $err -- 2.21.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 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 1 sibling, 1 reply; 12+ messages in thread From: Johannes Schindelin @ 2019-07-04 10:38 UTC (permalink / raw) To: Heiko Voigt; +Cc: paulus, max, git Hi Heiko, On Thu, 4 Jul 2019, Heiko Voigt wrote: > In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified", > 2014-09-09) the intention was to have detached HEAD shown when the --all > argument is given. > > This was solved by appending HEAD to the revs list. By doing that the > behavior using the --not argument is now broken, since that inverts the > meaning of all following arguments passed to git rev-parse. > > Lets fix this by prepending HEAD instead of appending, this way there > can not be any '--not' in front. > > This was discovered because > > gitk --all --not origin/master > > does not display the same revs as > > gitk --all ^origin/master > > which it should. > > Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Good description. > --- > gitk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gitk b/gitk > index a14d7a1..19d95cd 100755 > --- a/gitk > +++ b/gitk > @@ -295,7 +295,7 @@ proc parseviewrevs {view revs} { > if {$revs eq {}} { > set revs HEAD > } elseif {[lsearch -exact $revs --all] >= 0} { > - lappend revs HEAD > + linsert revs 0 HEAD For a moment, I wondered whether there is any case where `HEAD` might not be appropriate as first argument, but you're right, the revision parsing machinery allows mixing options and rev arguments. In short: this patch looks good to me. Thanks, Dscho > } > if {[catch {set ids [eval exec git rev-parse $revs]} err]} { > # we get stdout followed by stderr in $err > -- > 2.21.0 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-04 10:38 ` Johannes Schindelin @ 2019-07-04 11:31 ` Heiko Voigt 0 siblings, 0 replies; 12+ messages in thread From: Heiko Voigt @ 2019-07-04 11:31 UTC (permalink / raw) To: Johannes Schindelin; +Cc: paulus, max, git Hi Dscho, On Thu, Jul 04, 2019 at 12:38:44PM +0200, Johannes Schindelin wrote: > On Thu, 4 Jul 2019, Heiko Voigt wrote: [...] > > Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> > > Good description. Thanks. I am actually surprised that for almost 5 years nobody noticed this. It seems either nobody is using --not this way or everyone took it as a feature that HEAD would be removed and will complain once this get released ;) I usually use the caret notation, but I guess this time I was lazy and the dash was easier to type... > > --- > > gitk | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/gitk b/gitk > > index a14d7a1..19d95cd 100755 > > --- a/gitk > > +++ b/gitk > > @@ -295,7 +295,7 @@ proc parseviewrevs {view revs} { > > if {$revs eq {}} { > > set revs HEAD > > } elseif {[lsearch -exact $revs --all] >= 0} { > > - lappend revs HEAD > > + linsert revs 0 HEAD > > For a moment, I wondered whether there is any case where `HEAD` might not > be appropriate as first argument, but you're right, the revision parsing > machinery allows mixing options and rev arguments. Thanks for double checking. > In short: this patch looks good to me. Thanks for the quick review! Cheers Heiko ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-04 8:09 [PATCH] gitk: fix --all behavior combined with --not Heiko Voigt 2019-07-04 10:38 ` Johannes Schindelin @ 2019-07-08 19:01 ` Junio C Hamano 2019-07-09 4:55 ` Junio C Hamano 1 sibling, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2019-07-08 19:01 UTC (permalink / raw) To: Heiko Voigt; +Cc: paulus, max, git Heiko Voigt <hvoigt@hvoigt.net> writes: > In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified", > 2014-09-09) the intention was to have detached HEAD shown when the --all > argument is given. The "do we have --all?" test added by that old commit is not quite satisfying in the first place. E.g. we do not check if there is a double-dash before it. This change also relies on an ancient design mistake of allowing non-dashed options before a dashed one, adding more to dissatisfaction by making a future change to correct the design mistake harder. I think in the longer term we should consider changing "git rev-parse --all" to include HEAD in the concept of "all refs" instead. But in the meantime, this patch is not making things drastically wrong, so let's take it as is. Thanks. > > Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> > --- > gitk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gitk b/gitk > index a14d7a1..19d95cd 100755 > --- a/gitk > +++ b/gitk > @@ -295,7 +295,7 @@ proc parseviewrevs {view revs} { > if {$revs eq {}} { > set revs HEAD > } elseif {[lsearch -exact $revs --all] >= 0} { > - lappend revs HEAD > + linsert revs 0 HEAD > } > if {[catch {set ids [eval exec git rev-parse $revs]} err]} { > # we get stdout followed by stderr in $err ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 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:44 ` Heiko Voigt 0 siblings, 2 replies; 12+ messages in thread From: Junio C Hamano @ 2019-07-09 4:55 UTC (permalink / raw) To: Heiko Voigt; +Cc: paulus, max, git Junio C Hamano <gitster@pobox.com> writes: > Heiko Voigt <hvoigt@hvoigt.net> writes: > >> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified", >> 2014-09-09) the intention was to have detached HEAD shown when the --all >> argument is given. > > The "do we have --all?" test added by that old commit is not quite > satisfying in the first place. E.g. we do not check if there is a > double-dash before it. This change also relies on an ancient design > mistake of allowing non-dashed options before a dashed one, adding > more to dissatisfaction by making a future change to correct the > design mistake harder. Actually, I do not think this patch is a good idea. This command $ git rev-list $commit --not --all is a good way to ask "See if $commit is anchored to the repository with any of refs or HEAD". It does so by marking the tips of all refs and HEAD as negative (i.e. stop the travesal) endpoints and mark given $commit as a positive endpoint. The commits listed by feeding the output of the above to the rev-list command would be the ones that are only reachable by $commit and not any of the refs. The "--all" in rev-list family (including "git log") unconditionally include HEAD. The glitch here is that "--all" in rev-parse does not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make "--all" imply "HEAD". That is, the original code we can see in your patch appends "HEAD" to the list of args, so $ gitk $commit --not --all ends up in running $ git rev-parse $commit --not --all HEAD and the result are used as the traversal endpoints (aka "arguments to rev-list command"). And that is exactly what the user wants to see happen. But you do not want to *prepend* HEAD to make the command line look this way: $ git rev-parse HEAD $commit --not --all which I think is what your patch does. It asks a completely different question: what are the commits reachable from either HEAD or $commit that are not reachable from any of our refs? What you want to do is to make sure your additional "HEAD" always goes together with the existing "--all" the user gave you. As the code is _already_ finding the _exact_ location on the command line where "--all" appears, I think you can go one step further and make sure you insert the "HEAD" immediately after "--all", as that exactly matches what you (and the ancient 4d5e1b1319) are trying to achieve: pretend as if "--all" always include "HEAD", even when it is detached. This is orthogonal to the question I posed in my earlier reply (i.e. "we found --all; is it really a 'give me all refs' request given by the user, or something else (is it an argument to another option, like "--grep '--all'", or is it pathspec after '--'), but assuming that we have reliably found the "--all" on the command line the user meant as "give me all refs", I think inserting HEAD immediately after that location would be the right solution. It is incorrect to unconditionally append as your original example shows, but it is equally incorrect to unconditionally prepend. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 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 7:44 ` Heiko Voigt 1 sibling, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2019-07-09 5:16 UTC (permalink / raw) To: Heiko Voigt; +Cc: paulus, max, git Junio C Hamano <gitster@pobox.com> writes: > The "--all" in rev-list family (including "git log") unconditionally > include HEAD. The glitch here is that "--all" in rev-parse does > not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make "--all" > imply "HEAD". And it becomes really tempting to get rid of that "let's tweak --all" hack and declare that "rev-parse --all" is simply buggy, proposing a simple "bugfix" that may look like this (not even compile tested, but you get the idea). 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; } ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-09 5:16 ` Junio C Hamano @ 2019-07-10 7:58 ` Heiko Voigt 2019-07-10 18:40 ` Junio C Hamano 0 siblings, 1 reply; 12+ messages in thread From: Heiko Voigt @ 2019-07-10 7:58 UTC (permalink / raw) To: Junio C Hamano; +Cc: paulus, max, git, Johannes Schindelin On Mon, Jul 08, 2019 at 10:16:50PM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > The "--all" in rev-list family (including "git log") unconditionally > > include HEAD. The glitch here is that "--all" in rev-parse does > > not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make "--all" > > imply "HEAD". > > And it becomes really tempting to get rid of that "let's tweak > --all" hack and declare that "rev-parse --all" is simply buggy, > proposing a simple "bugfix" that may look like this (not even > compile tested, but you get the idea). Thanks for this nice pointer. Lets think about this a little more, because this would give us a proper solution. There would be a need to be backwards compatible to not break peoples scripts right? The documentation says --all "Show all refs found in refs/" so IMO we need some extra option that changes the '--all' 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? 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; > } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-10 7:58 ` Heiko Voigt @ 2019-07-10 18:40 ` Junio C Hamano 2019-07-11 12:24 ` Heiko Voigt 2019-07-11 17:11 ` Johannes Sixt 0 siblings, 2 replies; 12+ messages in thread From: Junio C Hamano @ 2019-07-10 18:40 UTC (permalink / raw) To: Heiko Voigt; +Cc: paulus, max, git, Johannes Schindelin 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; >> } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-10 18:40 ` Junio C Hamano @ 2019-07-11 12:24 ` Heiko Voigt 2019-07-11 18:55 ` Junio C Hamano 2019-07-11 17:11 ` Johannes Sixt 1 sibling, 1 reply; 12+ messages in thread From: Heiko Voigt @ 2019-07-11 12:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: paulus, max, git, Johannes Schindelin On Wed, Jul 10, 2019 at 11:40:50AM -0700, Junio C Hamano wrote: > 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? Sorry for being not specific enough. I would be aiming for the latter and gitk would prepend --all-include-head to its rev-parse call. To have some code to talk about something like this (based on your pointer and also not compile tested): diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c index f8bbe6d47e..03928ee566 100644 --- a/builtin/rev-parse.c +++ b/builtin/rev-parse.c @@ -585,6 +585,7 @@ static void handle_ref_opt(const char *pattern, const char *prefix) int cmd_rev_parse(int argc, const char **argv, const char *prefix) { int i, as_is = 0, verify = 0, quiet = 0, revs_count = 0, type = 0; + int all_include_head = 0; int did_repo_setup = 0; int has_dashdash = 0; int output_prefix = 0; @@ -764,8 +765,14 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix) } continue; } + if (!strcmp(arg, "--all-include-head")) { + all_include_head = 1; + continue; + } if (!strcmp(arg, "--all")) { for_each_ref(show_reference, NULL); + if (all_include_head) + head_ref(show_reference, NULL); clear_ref_exclusion(&ref_excludes); continue; } diff --git a/gitk-git/gitk b/gitk-git/gitk index a14d7a16b2..ddd1de5377 100755 --- a/gitk-git/gitk +++ b/gitk-git/gitk @@ -294,8 +294,8 @@ proc parseviewrevs {view revs} { if {$revs eq {}} { set revs HEAD - } elseif {[lsearch -exact $revs --all] >= 0} { - lappend revs HEAD + } else { + linsert revs 0 --all-include-head } if {[catch {set ids [eval exec git rev-parse $revs]} err]} { # we get stdout followed by stderr in $err > 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. Yes the former would not make anything better. > If the latter, I am not sure what the endgame should be. Please see the diff above. > 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? Yes probably, but in my experience, if some behavior is around for a long time, someone will rely on it and rev-parse seems like a candidate that might get used in scripts for CIs or similar. E.g. in a bare repo someone might explicitely want to omit HEAD. > 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? > 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] > 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. Well this should be better than the current solution. But there is still your point about not taking -- into account. So how about my backwards compatible suggestion above, what do you think? Cheers Heiko [1] https://public-inbox.org/git/xmqqsika2c2i.fsf@gitster.dls.corp.google.com/ ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-11 12:24 ` Heiko Voigt @ 2019-07-11 18:55 ` Junio C Hamano 0 siblings, 0 replies; 12+ messages in thread From: Junio C Hamano @ 2019-07-11 18:55 UTC (permalink / raw) To: Heiko Voigt; +Cc: paulus, max, git, Johannes Schindelin Heiko Voigt <hvoigt@hvoigt.net> writes: > 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. >> 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. >> 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-10 18:40 ` Junio C Hamano 2019-07-11 12:24 ` Heiko Voigt @ 2019-07-11 17:11 ` Johannes Sixt 1 sibling, 0 replies; 12+ messages in thread From: Johannes Sixt @ 2019-07-11 17:11 UTC (permalink / raw) To: Junio C Hamano, Heiko Voigt; +Cc: paulus, max, git, Johannes Schindelin 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] gitk: fix --all behavior combined with --not 2019-07-09 4:55 ` Junio C Hamano 2019-07-09 5:16 ` Junio C Hamano @ 2019-07-10 7:44 ` Heiko Voigt 1 sibling, 0 replies; 12+ messages in thread From: Heiko Voigt @ 2019-07-10 7:44 UTC (permalink / raw) To: Junio C Hamano; +Cc: paulus, max, git On Mon, Jul 08, 2019 at 09:55:00PM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Heiko Voigt <hvoigt@hvoigt.net> writes: > > > >> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified", > >> 2014-09-09) the intention was to have detached HEAD shown when the --all > >> argument is given. > > > > The "do we have --all?" test added by that old commit is not quite > > satisfying in the first place. E.g. we do not check if there is a > > double-dash before it. This change also relies on an ancient design > > mistake of allowing non-dashed options before a dashed one, adding > > more to dissatisfaction by making a future change to correct the > > design mistake harder. > > Actually, I do not think this patch is a good idea. > [...] > > As the code is _already_ finding the _exact_ location on the command > line where "--all" appears, I think you can go one step further and > make sure you insert the "HEAD" immediately after "--all", as that > exactly matches what you (and the ancient 4d5e1b1319) are trying to > achieve: pretend as if "--all" always include "HEAD", even when it > is detached. > > This is orthogonal to the question I posed in my earlier reply > (i.e. "we found --all; is it really a 'give me all refs' request > given by the user, or something else (is it an argument to another > option, like "--grep '--all'", or is it pathspec after '--'), but > assuming that we have reliably found the "--all" on the command line > the user meant as "give me all refs", I think inserting HEAD > immediately after that location would be the right solution. It is > incorrect to unconditionally append as your original example shows, > but it is equally incorrect to unconditionally prepend. Yes I agree, there are too many other use cases that my change will break. I tried to replace a hack with another quick hack, but that did not make it better. Will reply to the other mail with some more questions. Cheers Heiko ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-07-11 18:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).