{"thread":{"id":"36406","subject":"Re: [PATCH 5/5] completion: fix completion of certain aliases","startedAt":"2014-04-13T07:08:23Z","lastAt":"2014-04-19T01:26:58Z","messageCount":3,"participants":["Gábor Szeder","Junio C Hamano","Felipe Contreras"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"238807","messageId":"E1WZEWT-0002R7-1d@iramx2.ira.uni-karlsruhe.de","threadId":"36406","inReplyTo":null,"subject":"Re: [PATCH 5/5] completion: fix completion of certain aliases","fromName":"Gábor Szeder","fromEmail":"szeder@ira.uka.de","sentAt":"2014-04-13T07:08:23Z","receivedAt":"2014-04-13T07:08:23Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\nHi,\n\n[I'm travelling, so I don't have the means to actually try out this patch, and it might take a while a to reply to any follow ups.]\n\nOn Apr 10, 2014 12:03 AM, Junio C Hamano wrote:\n>\n> Felipe Contreras writes: \n>\n> > Some commands need the first word to determine the actual action that is \n> > being executed, however, the command is wrong when we use an alias, for \n> > example 'alias.p=push', if we try to complete 'git p origin ', the \n> > result would be wrong because __git_complete_remote_or_refspec() doesn't \n> > know where it come from. \n> > \n> > So let's override words[1], so the alias 'p' is override by the actual \n> > command, 'push'. \n> > \n> > Reported-by: Aymeric Beaumet \n> > Signed-off-by: Felipe Contreras \n> > --- \n>\n> Does \"some commands\" above refer to anything that uses \n> __git_complete_remote_or_refspec, or is the set of commands larger \n> than that? \n>\n> I am wondering if it is safer to introduce a new \"local\" variable \n> that is set by the caller of __git_complete_remote_or_refspec and \n> inspected by __git_complete_remote_or_refspec (instead of words[1]) \n> to communiate the real name of the git subcommand being completed, \n> without touching words[] in place. \n>\n> That way, we wouldn't have to worry about all the other references \n> of words[c], words[i], words[CURRENT] etc. in the script seeing the \n> word that the end-user did not type and did not actually appear on \n> the command line. \n>\n> But perhaps we muck with the contents of words[] in a similar way in \n> many different places in the existing completion code often enough \n> that such an attempt not to touch the words[] array does not buy us \n> much safety anyway.  I didn't check (and that is why I am asking \n> with \"I am wondering...\").\n\nwords[] is just fine, we never modify it after it is filled by _get_comp_words_by_ref() at the very beginning.\n\nThe root of the problem is that the expected position of the name of the git command in __git_complete_remote_or_refspec() is hardcoded as words[1], but that is not the case when:\n\n  1) it's an alias, as in Felipe's example: git p ori, because while the index is ok, the content is not.\n\n  2) in presence of options of the main git command: git -c foo=bar push ori, because the index is off.\n\n  3) the command is a shell alias for which the user explicitly set the completion function with __git_complete() (at his own risk): alias gp=\"git push\"; __git_complete gp _git_push; gp ori Neither the index nor the content are ok.\n\nFixing the hard-coded indexing would only solve 2) but not 1) and 3), as it obviously couldn't turn the git or shell alias into a git command on its own.\n\nFelipe's patch only deals with 1), as it only kicks in in case of a git alias.\n\nCommunicating the name of the git command to __git_complete_remote_or_refspec() by its callers via a new variable as suggested by Junio, or perhaps by an additional parameter to the function is IMHO the right thing to do, because, unless I'm missing something, it would make all three cases work.\n\nBest,\nGábor\n\n> Thanks, will queue. \n>\n> [Ram and Szeder CC'ed as they appear in shortlog for the past 12 \n> months]. \n>\n> >  contrib/completion/git-completion.bash | 1 + \n> >  contrib/completion/git-completion.zsh  | 1 + \n> >  2 files changed, 2 insertions(+) \n> > \n> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash \n> > index 9525343..893ae5d 100644 \n> > --- a/contrib/completion/git-completion.bash \n> > +++ b/contrib/completion/git-completion.bash \n> > @@ -2547,6 +2547,7 @@ __git_main () \n> >  \n> >  local expansion=$(__git_aliased_command \"$command\") \n> >  if [ -n \"$expansion\" ]; then \n> > + words[1]=$expansion \n> >  completion_func=\"_git_${expansion//-/_}\" \n> >  declare -f $completion_func >/dev/null && $completion_func \n> >  fi \n> > diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh \n> > index 6b77968..9f6f0fa 100644 \n> > --- a/contrib/completion/git-completion.zsh \n> > +++ b/contrib/completion/git-completion.zsh \n> > @@ -104,6 +104,7 @@ __git_zsh_bash_func () \n> >  \n> >  local expansion=$(__git_aliased_command \"$command\") \n> >  if [ -n \"$expansion\" ]; then \n> > + words[1]=$expansion \n> >  completion_func=\"_git_${expansion//-/_}\" \n> >  declare -f $completion_func >/dev/null && $completion_func \n> >  fi \n"},{"id":"238861","messageId":"xmqqmwfnoe7m.fsf@gitster.dls.corp.google.com","threadId":"36406","inReplyTo":"E1WZEWT-0002R7-1d@iramx2.ira.uni-karlsruhe.de","subject":"Re: [PATCH 5/5] completion: fix completion of certain aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-14T20:20:29Z","receivedAt":"2014-04-14T20:20:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gábor Szeder writes:\n\n> words[] is just fine, we never modify it after it is filled by\n> _get_comp_words_by_ref() at the very beginning.\n\nHmph. I would have understood if the latter were \"we never look at\nit (to decide what to do)\". \"we never modify it\" does not sound\nlike an enough justification behind \"words[] is just fine\"---maybe I\nam not reading you correctly.\n\n> The root of the problem is that the expected position of the name\n> of the git command in __git_complete_remote_or_refspec() is\n> hardcoded as words[1], but that is not the case when:\n>\n> 1) it's an alias, as in Felipe's example: git p ori,\n> because while the index is ok, the content is not.\n>\n> 2) in presence of options of the main git command: git -c\n> foo=bar push ori, because the index is off.\n>\n> 3) the command is a shell alias for which the user explicitly\n> set the completion function with __git_complete() (at his own\n> risk): alias gp=\"git push\"; __git_complete gp _git_push; gp\n> ori Neither the index nor the content are ok.\n>\n> Fixing the hard-coded indexing would only solve 2) but not 1) and\n> 3), as it obviously couldn't turn the git or shell alias into a\n> git command on its own.\n>\n> Felipe's patch only deals with 1), as it only kicks in in case of\n> a git alias.\n\nYeah, do completions for commands (not just for the ones that use\nremote-or-refspec Felipe's patch addresses) have trouble with the\nlatter two in general? If that is the case,...\n\n> Communicating the name of the git command to\n> __git_complete_remote_or_refspec() by its callers via a new\n> variable as suggested by Junio, or perhaps by an additional\n> parameter to the function is IMHO the right thing to do, because,\n> unless I'm missing something, it would make all three cases work.\n\n... while the above analysis may be correct, taking Felipe's patch\nto address only (1) and leaving a solution to the more general\nwords[1] problem for other patches on top might not be too bad an\napproach.\n\nUnless\n\n (A) remote-or-refspec thing is the primary offender, and other\n commands do not suffer from the words[1] problem, in which case\n I tend to agree that an additional parameter would be the way\n to go (there are only a few callers of the function); or\n\n (B) even if words[1] problem is more widespread, such a more\n general solution to all three issues can be coded cleanly and\n quickly, without having to have Felipe's patch as a stop-gap\n measure.\n\nthat is.\n\nI'll keep Felipe's patch in the meantime to 'pu'.\n\nThanks.\n"},{"id":"239096","messageId":"5351d0e2951ca_364af2f2ec6f@nysa.notmuch","threadId":"36406","inReplyTo":"xmqqmwfnoe7m.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 5/5] completion: fix completion of certain aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-19T01:26:58Z","receivedAt":"2014-04-19T01:26:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Gábor Szeder writes:\n> \n> > words[] is just fine, we never modify it after it is filled by\n> > _get_comp_words_by_ref() at the very beginning.\n> \n> Hmph. I would have understood if the latter were \"we never look at\n> it (to decide what to do)\". \"we never modify it\" does not sound\n> like an enough justification behind \"words[] is just fine\"---maybe I\n> am not reading you correctly.\n> \n> > The root of the problem is that the expected position of the name\n> > of the git command in __git_complete_remote_or_refspec() is\n> > hardcoded as words[1], but that is not the case when:\n> >\n> > 1) it's an alias, as in Felipe's example: git p ori,\n> > because while the index is ok, the content is not.\n> >\n> > 2) in presence of options of the main git command: git -c\n> > foo=bar push ori, because the index is off.\n> >\n> > 3) the command is a shell alias for which the user explicitly\n> > set the completion function with __git_complete() (at his own\n> > risk): alias gp=\"git push\"; __git_complete gp _git_push; gp\n> > ori Neither the index nor the content are ok.\n> >\n> > Fixing the hard-coded indexing would only solve 2) but not 1) and\n> > 3), as it obviously couldn't turn the git or shell alias into a\n> > git command on its own.\n> >\n> > Felipe's patch only deals with 1), as it only kicks in in case of\n> > a git alias.\n\nWhich is the far more common use-case, and the problem I've seen people report\nmultiple times in multiple media.\n\n> Yeah, do completions for commands (not just for the ones that use\n> remote-or-refspec Felipe's patch addresses) have trouble with the\n> latter two in general? If that is the case,...\n> \n> > Communicating the name of the git command to\n> > __git_complete_remote_or_refspec() by its callers via a new\n> > variable as suggested by Junio, or perhaps by an additional\n> > parameter to the function is IMHO the right thing to do, because,\n> > unless I'm missing something, it would make all three cases work.\n> \n> ... while the above analysis may be correct, taking Felipe's patch\n> to address only (1) and leaving a solution to the more general\n> words[1] problem for other patches on top might not be too bad an\n> approach.\n> \n> Unless\n> \n> (A) remote-or-refspec thing is the primary offender, and other\n> commands do not suffer from the words[1] problem, in which case\n> I tend to agree that an additional parameter would be the way\n> to go (there are only a few callers of the function); or\n\nSince I already fixed the problem (all 3) years ago[1], you can take a look at\nthe patch and see which commands which use a hard-coded index value might have\nreal issues. My guess is that it's more than just remote-or-refspec, but I\ndon't have the incentive to look deeper into this (the issue is solved for me).\n\n> (B) even if words[1] problem is more widespread, such a more\n> general solution to all three issues can be coded cleanly and\n> quickly, without having to have Felipe's patch as a stop-gap\n> measure.\n\nI already sent two patches, one that solves all the problems, and one that\nsolves the most important one.\n\nI would gladly revisit my old patch and see which of those changes are really\nnecessary and solve a real issue, *if* I knew the resulting patch wouldn't get\nthe same road-blockers as the old one did; namely being held to higher\nstandards than the current code.\n\nI say it's more important to fix the real issues real people have than hold on\nto arbitrary standards which might force the bug to remain present for years\njust because some variable was not documented in the original patch (just like\nall other variables in the script)... But that's just me.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/197226\n\n-- \nFelipe Contreras"}]}