All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Thomas Rast <trast@student.ethz.ch>
Subject: Re: [PATCH v3] completion: add new _GIT_complete helper
Date: Mon, 7 May 2012 11:22:13 +0200	[thread overview]
Message-ID: <20120507092213.GO2164@goldbirke> (raw)
In-Reply-To: <CAMP44s3q-X7W5qeu6LZzu13C6SfhEZy9i4AfJ9Sszcou52MsGw@mail.gmail.com>

Hi,


On Mon, May 07, 2012 at 02:20:54AM +0200, Felipe Contreras wrote:
> In fact, it could be even simpler:
> 
> _GIT_complete gf fetch

That would be even better; just need to take care of 'cherry-pick' and
the like.

> >> > Besides, this example won't work, because the completion for 'git
> >> > fetch' uses __git_complete_remote_or_refspec(), which in turn relies
> >> > on finding out the name of the git command from the word on the
> >> > command line, and it won't be able to do that from 'gf'.

> It does work... on my branch.

I though the patch was supposed to be applied on git.git's master.  I
didn't know what else you had on your branch, obviously.

> If you have another example that works, feel free to suggest it

I played around with 'gb' as 'git branch' and 'gc' as 'git checkout',
they seemed to work properly, and they both use $words directly or
indirectly.  I suspect most of them Just Works, except those using
__git_complete_remote_or_refspec(), and _git_bundle() as you mention
below, and perhaps a few surprises we hadn't spotted yet.

> >> replace with another command that
> >> doesn't use 'words', and it would work.
> >
> > That it doesn't work has nothing to do with $words.  The problem is that
> > __git_complete_remote_or_refspec() expects to find the git command in
> > ${words[1]}, but in case of an alias it can't.
> 
> ${words[1]} is part of $words.

The problem is not with $words per se, but with the '1'.

> And BTW, git bundle also fails similarly.

Indeed; using __git_find_on_cmdline() and checking which subcommand it
found, if any, would allow us to get rid of all numbers from that
function.

> Also BTW, git fetch is already broken anyway:
> 
>  git --no-pager fetch <TAB>
> 
> So don't blame my patch :)

Yeah, I know, but that's broken since "forever".  However, I think
that would be a separate, though related topic, because it's not
required to make completion for alias work.

> >> > I remember we discussed this in an earlier round, and you even
> >> > suggested a possible fix (passing the command name as argument to
> >> > __git_complete_remote_or_refspec()).  I think that's the right thing
> >> > to do here.

> That's not enough to make 'git fetch' work, try it.

As already mentioned it earlier in this thread, the iteration over
$words in __git_complete_remote_or_refspec() have to be fixed, too.

> >> >> +     __git_func "$@"

> Sure, but it was just 4 more characters that didn't hurt anybody. Your
> version makes passing those arguments more difficult, so I see no need
> to try to implement that.

OK.  I doesn't hurt, but I think it's more important to avoid
fork()+exec() overheads than to pass arguments whose values are
readily available in other variables anyway.


Gábor

      reply	other threads:[~2012-05-07  9:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-05 15:23 [PATCH v3] completion: add new _GIT_complete helper Felipe Contreras
2012-05-05 15:54 ` Jonathan Nieder
2012-05-05 16:38   ` Felipe Contreras
2012-05-05 16:47     ` Jonathan Nieder
2012-05-05 16:52       ` Jonathan Nieder
2012-05-05 17:20       ` Felipe Contreras
2012-05-05 17:33         ` Jonathan gives feedback --> flamewars inevitable? (Re: [PATCH v3] completion: add new _GIT_complete helper) Jonathan Nieder
2012-05-05 18:23           ` Felipe Contreras
2012-05-05 18:39             ` Jonathan gives feedback --> flamewars inevitable? Jonathan Nieder
2012-05-05 18:42             ` Jonathan Nieder
2012-05-06  5:23           ` Jonathan gives feedback --> flamewars inevitable? (Re: [PATCH v3] completion: add new _GIT_complete helper) Tay Ray Chuan
2012-05-14  9:11             ` Felipe Contreras
2012-05-05 17:44         ` [PATCH v3] completion: add new _GIT_complete helper Jonathan Nieder
2012-05-06 10:30   ` SZEDER Gábor
2012-05-06 20:47     ` Jonathan Nieder
2012-05-06 11:14 ` SZEDER Gábor
2012-05-06 11:30   ` SZEDER Gábor
2012-05-06 11:36     ` SZEDER Gábor
2012-05-06 12:12   ` SZEDER Gábor
2012-05-06 20:53     ` Felipe Contreras
2012-05-06 20:37   ` Felipe Contreras
2012-05-06 23:32     ` SZEDER Gábor
2012-05-07  0:20       ` Felipe Contreras
2012-05-07  9:22         ` SZEDER Gábor [this message]

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

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

  git send-email \
    --in-reply-to=20120507092213.GO2164@goldbirke \
    --to=szeder@ira.uka.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=trast@student.ethz.ch \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.