All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Ted Pavlic <ted@tedpavlic.com>, git@vger.kernel.org
Subject: Re: [PATCH] Speedup bash completion loading
Date: Thu, 8 Oct 2009 08:02:06 -0700	[thread overview]
Message-ID: <20091008150206.GD9261@spearce.org> (raw)
In-Reply-To: <20091008132718.GA12161@tugrik.mns.mnsspb.ru>

Kirill Smelkov <kirr@mns.spb.ru> wrote:
> diff --git a/contrib/completion/Makefile b/contrib/completion/Makefile
> new file mode 100644
> index 0000000..a0fbb66
> --- /dev/null
> +++ b/contrib/completion/Makefile
> @@ -0,0 +1,11 @@
> +all	: git-completion.bash
> +
> +
> +git-completion.bash: git-completion.bash.in git-completion.bash.generate
> +	# Generate completions for binaries we have just built
> +	PATH="$(shell pwd)/..:$$PATH" ./git-completion.bash.generate

Is only one .. enough?  Isn't that putting us into the contrib
directory, and therefore not finding the 'git' we just compiled?

I'm also concerned that git-completion.bash.generate requires
bash to compile the completion for bash.  IMHO, if we are building
this code at compile time we shouldn't assume bash is available.
What if this is a sandboxed build environment using another shell
and /bin/bash isn't installed?

I think the git-completion.bash.generate code needs to be a bit
more sh agnostic than the completion routines themselves are.

> +# pregenerated stuff (to save load time)
> +__git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
> +__git_all_commandlist=__GIT_ALL_COMMANDLIST
> +__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST

This also makes testing the completion a bit more difficult, now
we have to build it before we can load it, making the testing cycle
actually be:

  make && . git-completion.bash

We probably should place a quick comment here to remind folks that
they need to build the script in order to test it properly.

-- 
Shawn.

  reply	other threads:[~2009-10-08 15:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05 10:03 [PATCH] Speedup bash completion loading Kirill Smelkov
2009-10-05 15:25 ` Shawn O. Pearce
2009-10-05 16:58   ` Kirill Smelkov
2009-10-05 19:18     ` Ted Pavlic
2009-10-08 13:27   ` Kirill Smelkov
2009-10-08 15:02     ` Shawn O. Pearce [this message]
2009-10-08 15:10       ` Kirill Smelkov
2009-10-09  9:09       ` Kirill Smelkov
2009-10-09 14:46         ` Shawn O. Pearce
2009-10-09 15:21           ` Kirill Smelkov
2009-10-09 15:39             ` Shawn O. Pearce
2009-10-09 16:08               ` Kirill Smelkov
2009-10-09 16:14                 ` Shawn O. Pearce
2009-10-10  0:57                   ` Junio C Hamano

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=20091008150206.GD9261@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=kirr@mns.spb.ru \
    --cc=ted@tedpavlic.com \
    /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.