{"thread":{"id":"48638","subject":"[PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","startedAt":"2018-06-03T16:38:47Z","lastAt":"2018-06-11T17:04:57Z","messageCount":7,"participants":["Rick van Hattem","Junio C Hamano","SZEDER Gábor","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"349177","messageId":"01020163c683e753-04629405-15f8-4a30-9dc3-e4e3f2a5aa26-000000@eu-west-1.amazonses.com","threadId":"48638","inReplyTo":null,"subject":"[PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"Rick van Hattem","fromEmail":"wolph@wol.ph","sentAt":"2018-06-03T16:38:43Z","receivedAt":"2018-06-03T16:38:47Z","isPatch":true,"sender":{"key":"wolph@wol.ph","avatar":"https://gravatar.com/avatar/3e86569f70d74646eb1f682e8d28f965114e44e067364be2154d74e7cb6b702a?d=mp&s=160"},"body":"The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n---\n contrib/completion/git-completion.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 12814e9bbf6be..7e2b9ad454930 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -348,7 +348,7 @@ __gitcomp ()\n \n # Clear the variables caching builtins' options when (re-)sourcing\n # the completion script.\n-if [[ -n ${ZSH_VERSION-} ]]; then\n+if [[ -n ${ZSH_NAME-} ]]; then\n \tunset $(set |sed -ne 's/^\\(__gitcomp_builtin_[a-zA-Z0-9_][a-zA-Z0-9_]*\\)=.*/\\1/p') 2>/dev/null\n else\n \tunset $(compgen -v __gitcomp_builtin_)\n\n--\nhttps://github.com/git/git/pull/500\n"},{"id":"349208","messageId":"xmqqr2ln5ide.fsf@gitster-ct.c.googlers.com","threadId":"48638","inReplyTo":"01020163c683e753-04629405-15f8-4a30-9dc3-e4e3f2a5aa26-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-06-04T03:40:45Z","receivedAt":"2018-06-04T03:40:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rick van Hattem <wolph@wol.ph> writes:\n\n> The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n> ---\n\nOverlong line, lack of sign-off.\n\n>  # Clear the variables caching builtins' options when (re-)sourcing\n>  # the completion script.\n> -if [[ -n ${ZSH_VERSION-} ]]; then\n> +if [[ -n ${ZSH_NAME-} ]]; then\n\nI am not a zsh user, and I do not know how reliable $ZSH_NAME can be\ntaken as an indication that we are running zsh and have already\nfound a usable git-completion-.bash script.\n\nI think what the proposed log message refers to as \"unsets\" is this\npart of the script:\n\n        ...\n        zstyle -s \":completion:*:*:git:*\" script script\n        if [ -z \"$script\" ]; then\n                local -a locations\n                local e\n                locations=(\n                        $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash\n                        ...\n                        )\n                for e in $locations; do\n                        test -f $e && script=\"$e\" && break\n                done\n        fi\n        ZSH_VERSION='' . \"$script\"\n\t...\n\nIf your ZSH_VERSION is empty, doesn't it indicate that the script\ndid not find a usable git-completion.bash script (to which it\noutsources the bulk of the completion work)?  I do agree segfaulting\nis not a friendly way to tell you that your setup is lacking to make\nit work, but I have a feeling that what you are seeing is an\nindication of a bigger problem, which will be sweeped under the rug\nwith this patch but without getting fixed...\n"},{"id":"349245","messageId":"CAJAwA=xjS6bWO2Cy+-pz-Es_RjvSyno9JNBGdPAve1L9ctOy-A@mail.gmail.com","threadId":"48638","inReplyTo":"xmqqr2ln5ide.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"Rick van Hattem","fromEmail":"wolph@wol.ph","sentAt":"2018-06-04T14:04:52Z","receivedAt":"2018-06-04T14:05:17Z","isPatch":true,"sender":{"key":"wolph@wol.ph","avatar":"https://gravatar.com/avatar/3e86569f70d74646eb1f682e8d28f965114e44e067364be2154d74e7cb6b702a?d=mp&s=160"},"body":"On 4 June 2018 at 05:40, Junio C Hamano <gitster@pobox.com> wrote:\nRick van Hattem <wolph@wol.ph> writes:\n\n> > The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n> > ---\n>\n> Overlong line, lack of sign-off.\n\nApologies for the long lines, I wrote the message on Github where this\nmessage is properly formatted, apparently the submitgit script can be\nconsidered broken as it truncates the message when converting to email.\n\nThe original message can be found here: https://github.com/git/git/pull/500\n\nBelow is the original message with proper formatting:\n\n> A recent change (94408dc) broke zsh for me (actually segfault zsh when\n> trying to use git completion)\n>\n> The reason is that the `git-completion.zsh` sets the `ZSH_VERSION`\n> variable to an empty string:\n>     ...\n>     ZSH_VERSION='' . \"$script\"\n>     ...\n>\n> I'm not sure if @szeder or @gitster used a different zsh version for\n> testing commit 94408dc but it segfaults zsh 5.5.1\n> (x86_64-apple-darwin15.6.0) on my OS X 10.11.6 machine.\n>\n> The proposed fix is quite simple and shouldn't break any backwards\n> compatibility.\n\nHopefully that clears a little bit of the confusion.\n\n> >  # Clear the variables caching builtins' options when (re-)sourcing\n> >  # the completion script.\n> > -if [[ -n ${ZSH_VERSION-} ]]; then\n> > +if [[ -n ${ZSH_NAME-} ]]; then\n>\n> I am not a zsh user, and I do not know how reliable $ZSH_NAME can be\n> taken as an indication that we are running zsh and have already\n> found a usable git-completion-.bash script.\n\nFrom what I gathered this variable has been available since 1995. But\nI'm not ZSH expert...\n\nYou can search for ZSH_NAME in the 3.0 changelog:\nhttp://zsh.sourceforge.net/Etc/changelog-3.0.html\n\n> I think what the proposed log message refers to as \"unsets\" is this\n> part of the script:\n\nAs mentioned above, I was referring to commit 94408dc which changed the\nbehaviour of the bash completion script.\n\nSpecifically:\n\n    ...\n    if [[ -n ${ZSH_VERSION-} ]]; then\n        unset $(set |sed -ne\n's/^\\(__gitcomp_builtin_[a-zA-Z0-9_][a-zA-Z0-9_]*\\)=.*/\\1/p')\n2>/dev/null\n    else\n        unset $(compgen -v __gitcomp_builtin_)\n    fi\n    ...\n\nBecause the ZSH script unsets the ZSH_VERSION variable (which is needed\nbecause the bash script checks for that later in the script) it defaults\nto the bash behaviour resulting in a segfault.\n\n> If your ZSH_VERSION is empty, doesn't it indicate that the script\n> did not find a usable git-completion.bash script (to which it\n> outsources the bulk of the completion work)?  I do agree segfaulting\n> is not a friendly way to tell you that your setup is lacking to make\n> it work, but I have a feeling that what you are seeing is an\n> indication of a bigger problem, which will be sweeped under the rug\n> with this patch but without getting fixed...\n\nThe git-completion.zsh script purposefully unsets the ZSH_VERSION\nbefore including the git-completion.bash script like this:\n\n    ...\n    ZSH_VERSION='' . \"$script\"\n    ...\n\nThe reason for that is (presumably) the check that's used within the\ngit-completion.bash script to warn ZSH users:\n\n    ...\n    if [[ -n ${ZSH_VERSION-} ]]; then\n    echo \"WARNING: this script is deprecated, please see\ngit-completion.zsh\" 1>&2\n    ...\n\n\n~rick\n\nOn 4 June 2018 at 05:40, Junio C Hamano <gitster@pobox.com> wrote:\n> Rick van Hattem <wolph@wol.ph> writes:\n>\n>> The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n>> ---\n>\n> Overlong line, lack of sign-off.\n>\n>>  # Clear the variables caching builtins' options when (re-)sourcing\n>>  # the completion script.\n>> -if [[ -n ${ZSH_VERSION-} ]]; then\n>> +if [[ -n ${ZSH_NAME-} ]]; then\n>\n> I am not a zsh user, and I do not know how reliable $ZSH_NAME can be\n> taken as an indication that we are running zsh and have already\n> found a usable git-completion-.bash script.\n>\n> I think what the proposed log message refers to as \"unsets\" is this\n> part of the script:\n>\n>         ...\n>         zstyle -s \":completion:*:*:git:*\" script script\n>         if [ -z \"$script\" ]; then\n>                 local -a locations\n>                 local e\n>                 locations=(\n>                         $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash\n>                         ...\n>                         )\n>                 for e in $locations; do\n>                         test -f $e && script=\"$e\" && break\n>                 done\n>         fi\n>         ZSH_VERSION='' . \"$script\"\n>         ...\n>\n> If your ZSH_VERSION is empty, doesn't it indicate that the script\n> did not find a usable git-completion.bash script (to which it\n> outsources the bulk of the completion work)?  I do agree segfaulting\n> is not a friendly way to tell you that your setup is lacking to make\n> it work, but I have a feeling that what you are seeing is an\n> indication of a bigger problem, which will be sweeped under the rug\n> with this patch but without getting fixed...\n"},{"id":"349496","messageId":"20180606114147.7753-1-szeder.dev@gmail.com","threadId":"48638","inReplyTo":"CAJAwA=xjS6bWO2Cy+-pz-Es_RjvSyno9JNBGdPAve1L9ctOy-A@mail.gmail.com","subject":"Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-06-06T11:41:47Z","receivedAt":"2018-06-06T11:42:01Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\n> On 4 June 2018 at 05:40, Junio C Hamano <gitster@pobox.com> wrote:\n> Rick van Hattem <wolph@wol.ph> writes:\n> \n> > > The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n> > > ---\n> >\n> > Overlong line, lack of sign-off.\n> \n> Apologies for the long lines, I wrote the message on Github where this\n> message is properly formatted, apparently the submitgit script can be\n> considered broken as it truncates the message when converting to email.\n> \n> The original message can be found here: https://github.com/git/git/pull/500\n\nThat link points to the pull request.  The important thing is the\nactual commit message, which can be found here:\n\n  https://github.com/git/git/pull/500/commits/b740bc3fedf419c7ee12364279cad84e1f2f7bb7\n\nSo submitgit neither truncated the commit message nor changed its\nformatting.\n\n> Below is the original message with proper formatting:\n> \n> > A recent change (94408dc) broke zsh for me (actually segfault zsh when\n> > trying to use git completion)\n> >\n> > The reason is that the `git-completion.zsh` sets the `ZSH_VERSION`\n> > variable to an empty string:\n> >     ...\n> >     ZSH_VERSION='' . \"$script\"\n> >     ...\n> >\n> > I'm not sure if @szeder or @gitster used a different zsh version for\n> > testing commit 94408dc but it segfaults zsh 5.5.1\n> > (x86_64-apple-darwin15.6.0) on my OS X 10.11.6 machine.\n\nI used \"zsh 5.1.1 (x86_64-ubuntu-linux-gnu)\", the one shipped in this\nLTS of a Debian derivative's derivative, for superficial testing:\nstarted zsh, dot-sourced 'git-completion.bash' (yes, .bash), it\nappeared to be doing what I thought it should be doing, great, done.\n\nI don't test 'git-completion.zsh': merely sourcing it doesn't seem to\nwork at all for me, I still get ZSH's git completion.\n\n> > The proposed fix is quite simple and shouldn't break any backwards\n> > compatibility.\n> \n> Hopefully that clears a little bit of the confusion.\n> \n> > >  # Clear the variables caching builtins' options when (re-)sourcing\n> > >  # the completion script.\n> > > -if [[ -n ${ZSH_VERSION-} ]]; then\n> > > +if [[ -n ${ZSH_NAME-} ]]; then\n> >\n> > I am not a zsh user, and I do not know how reliable $ZSH_NAME can be\n> > taken as an indication that we are running zsh and have already\n> > found a usable git-completion-.bash script.\n> \n> >From what I gathered this variable has been available since 1995. But\n> I'm not ZSH expert...\n> \n> You can search for ZSH_NAME in the 3.0 changelog:\n> http://zsh.sourceforge.net/Etc/changelog-3.0.html\n> \n> > I think what the proposed log message refers to as \"unsets\" is this\n> > part of the script:\n> \n> As mentioned above, I was referring to commit 94408dc which changed the\n> behaviour of the bash completion script.\n> \n> Specifically:\n> \n>     ...\n>     if [[ -n ${ZSH_VERSION-} ]]; then\n>         unset $(set |sed -ne\n> 's/^\\(__gitcomp_builtin_[a-zA-Z0-9_][a-zA-Z0-9_]*\\)=.*/\\1/p')\n> 2>/dev/null\n>     else\n>         unset $(compgen -v __gitcomp_builtin_)\n>     fi\n>     ...\n> \n> Because the ZSH script unsets the ZSH_VERSION variable (which is needed\n> because the bash script checks for that later in the script) it defaults\n> to the bash behaviour resulting in a segfault.\n\nI think this segfault issue should definitely be addressed in ZSH.  No\nmatter what foolish or downright wrong thing a script does, the shell\nshould not segfault.\n\n> > If your ZSH_VERSION is empty, doesn't it indicate that the script\n> > did not find a usable git-completion.bash script (to which it\n> > outsources the bulk of the completion work)?  I do agree segfaulting\n> > is not a friendly way to tell you that your setup is lacking to make\n> > it work, but I have a feeling that what you are seeing is an\n> > indication of a bigger problem, which will be sweeped under the rug\n> > with this patch but without getting fixed...\n> \n> The git-completion.zsh script purposefully unsets the ZSH_VERSION\n> before including the git-completion.bash script like this:\n> \n>     ...\n>     ZSH_VERSION='' . \"$script\"\n>     ...\n\nOh, I was not aware of this.  It does feel a bit hackish, doesn't it.\n\n> The reason for that is (presumably) the check that's used within the\n> git-completion.bash script to warn ZSH users:\n> \n>     ...\n>     if [[ -n ${ZSH_VERSION-} ]]; then\n>     echo \"WARNING: this script is deprecated, please see\n> git-completion.zsh\" 1>&2\n>     ...\n\nAnd, perhaps more importantly, to not load a bunch of shell functions\nthat follow that warning.\n\n> >>  # Clear the variables caching builtins' options when (re-)sourcing\n> >>  # the completion script.\n> >> -if [[ -n ${ZSH_VERSION-} ]]; then\n> >> +if [[ -n ${ZSH_NAME-} ]]; then\n\nLooking at $ZSH_VERSION is our standard check both in the completion\nand prompt scripts.  Changing only one of those checks to look at\n$ZSH_NAME instead brings inconcistency and confusion.\n\nI think it would be better to eliminate that \"let's pretend it's not\nZSH\" hack and make 'git-completion.zsh' more explicit by sourcing\n'git-completion.bash' something like this:\n\n  DOT_SOURCING_FROM_GIT_COMPLETION_ZSH=PleaseSkipDeprecatedFunctions . \"$script\"\n\n(with a more sensible variable name, of course :), and\n'git-completion.bash' should additionally check this variable as well.\n\n\n"},{"id":"349500","messageId":"CAJAwA=yhMumYY562k2hcoeABML5a6dsJsLwGwiQUsWHmbNF10Q@mail.gmail.com","threadId":"48638","inReplyTo":"20180606114147.7753-1-szeder.dev@gmail.com","subject":"Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"Rick van Hattem","fromEmail":"wolph@wol.ph","sentAt":"2018-06-06T12:19:56Z","receivedAt":"2018-06-06T12:20:20Z","isPatch":true,"sender":{"key":"wolph@wol.ph","avatar":"https://gravatar.com/avatar/3e86569f70d74646eb1f682e8d28f965114e44e067364be2154d74e7cb6b702a?d=mp&s=160"},"body":" On 6 June 2018 at 13:41, SZEDER Gábor <szeder.dev@gmail.com> wrote:\n>\n>> On 4 June 2018 at 05:40, Junio C Hamano <gitster@pobox.com> wrote:\n>> Rick van Hattem <wolph@wol.ph> writes:\n>>\n>> > > The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n>> > > ---\n>> >\n>> > Overlong line, lack of sign-off.\n>>\n>> Apologies for the long lines, I wrote the message on Github where this\n>> message is properly formatted, apparently the submitgit script can be\n>> considered broken as it truncates the message when converting to email.\n>>\n>> The original message can be found here: https://github.com/git/git/pull/500\n>\n> That link points to the pull request.  The important thing is the\n> actual commit message, which can be found here:\n>\n>   https://github.com/git/git/pull/500/commits/b740bc3fedf419c7ee12364279cad84e1f2f7bb7\n\nAh, now I see the problem. That was unintentional, I created this pull\nrequest through the Github interface where wrapping is auto enabled\nwhich masked the issue for me.\n\nThat's what I get for trying to use a webinterface instead of doing\nthis commandline... mea culpa.\n\n\n>> Because the ZSH script unsets the ZSH_VERSION variable (which is needed\n>> because the bash script checks for that later in the script) it defaults\n>> to the bash behaviour resulting in a segfault.\n>\n> I think this segfault issue should definitely be addressed in ZSH.  No\n> matter what foolish or downright wrong thing a script does, the shell\n> should not segfault.\n\nI agree, segfaulting is unacceptable behaviour.\n\n>> > If your ZSH_VERSION is empty, doesn't it indicate that the script\n>> > did not find a usable git-completion.bash script (to which it\n>> > outsources the bulk of the completion work)?  I do agree segfaulting\n>> > is not a friendly way to tell you that your setup is lacking to make\n>> > it work, but I have a feeling that what you are seeing is an\n>> > indication of a bigger problem, which will be sweeped under the rug\n>> > with this patch but without getting fixed...\n>>\n>> The git-completion.zsh script purposefully unsets the ZSH_VERSION\n>> before including the git-completion.bash script like this:\n>>\n>>     ...\n>>     ZSH_VERSION='' . \"$script\"\n>>     ...\n>\n> Oh, I was not aware of this.  It does feel a bit hackish, doesn't it.\n\nYes, it definitely does feel hackish but since this has been the case\nfor a long time I worry about breaking backwards compatibility with\npeoples shell configs by changing the behaviour now.\n\n>> The reason for that is (presumably) the check that's used within the\n>> git-completion.bash script to warn ZSH users:\n>>\n>>     ...\n>>     if [[ -n ${ZSH_VERSION-} ]]; then\n>>     echo \"WARNING: this script is deprecated, please see\n>> git-completion.zsh\" 1>&2\n>>     ...\n>\n> And, perhaps more importantly, to not load a bunch of shell functions\n> that follow that warning.\n>\n>> >>  # Clear the variables caching builtins' options when (re-)sourcing\n>> >>  # the completion script.\n>> >> -if [[ -n ${ZSH_VERSION-} ]]; then\n>> >> +if [[ -n ${ZSH_NAME-} ]]; then\n>\n> Looking at $ZSH_VERSION is our standard check both in the completion\n> and prompt scripts.  Changing only one of those checks to look at\n> $ZSH_NAME instead brings inconcistency and confusion.\n>\n> I think it would be better to eliminate that \"let's pretend it's not\n> ZSH\" hack and make 'git-completion.zsh' more explicit by sourcing\n> 'git-completion.bash' something like this:\n>\n>   DOT_SOURCING_FROM_GIT_COMPLETION_ZSH=PleaseSkipDeprecatedFunctions . \"$script\"\n>\n> (with a more sensible variable name, of course :), and\n> 'git-completion.bash' should additionally check this variable as well.\n\nI agree, that would be a better solution.\n\nFor the time being I would opt for either reverting 94408dc or\nimplementing this commit though.\n\n~rick\n"},{"id":"349593","messageId":"20180607050854.GA6567@aiede.svl.corp.google.com","threadId":"48638","inReplyTo":"CAJAwA=xjS6bWO2Cy+-pz-Es_RjvSyno9JNBGdPAve1L9ctOy-A@mail.gmail.com","subject":"Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-06-07T05:08:54Z","receivedAt":"2018-06-07T05:09:03Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRick van Hattem wrote:\n> On 4 June 2018 at 05:40, Junio C Hamano <gitster@pobox.com> wrote:\n\n>> Overlong line, lack of sign-off.\n>\n> Apologies for the long lines, I wrote the message on Github where this\n> message is properly formatted, apparently the submitgit script can be\n> considered broken as it truncates the message when converting to email.\n>\n> The original message can be found here: https://github.com/git/git/pull/500\n>\n> Below is the original message with proper formatting:\n>\n>> A recent change (94408dc) broke zsh for me (actually segfault zsh when\n>> trying to use git completion)\n>>\n>> The reason is that the `git-completion.zsh` sets the `ZSH_VERSION`\n>> variable to an empty string:\n>>     ...\n>>     ZSH_VERSION='' . \"$script\"\n>>     ...\n>>\n>> I'm not sure if @szeder or @gitster used a different zsh version for\n>> testing commit 94408dc but it segfaults zsh 5.5.1\n>> (x86_64-apple-darwin15.6.0) on my OS X 10.11.6 machine.\n>>\n>> The proposed fix is quite simple and shouldn't break any backwards\n>> compatibility.\n>\n> Hopefully that clears a little bit of the confusion.\n\nThanks.  That helps a little, but it's missing a crucial piece: may we\nforge your sign-off?  See Documentation/SubmittingPatches section\n[[sign-off]] (\"Certify your work\") for more details about what this\nmeans.\n\nThanks,\nJonathan\n"},{"id":"349916","messageId":"xmqqefhdckzx.fsf@gitster-ct.c.googlers.com","threadId":"48638","inReplyTo":"xmqqr2ln5ide.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-06-11T17:04:50Z","receivedAt":"2018-06-11T17:04:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Rick van Hattem <wolph@wol.ph> writes:\n>\n>> The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting.\n>> ---\n>\n> Overlong line, lack of sign-off.\n>\n>>  # Clear the variables caching builtins' options when (re-)sourcing\n>>  # the completion script.\n>> -if [[ -n ${ZSH_VERSION-} ]]; then\n>> +if [[ -n ${ZSH_NAME-} ]]; then\n>\n>       ...\n>         ZSH_VERSION='' . \"$script\"\n> \t...\n>\n> If your ZSH_VERSION is empty, doesn't it indicate that the script\n> did not find a usable git-completion.bash script (to which it\n> outsources the bulk of the completion work)?\n\nAh, I was totally mis-reading the script (and partly was confused by\nyour use of \"unset\").  ZSH_VERSION is reset to an empty string,\nwhich breaks the check later done in the bash completion script.\n\n"}]}