All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <bebarino@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
	git@vger.kernel.org, Clemens Buchacher <drizzd@aon.at>,
	Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [PATCH/RFC 2/2] completion: allow use without compiling
Date: Mon, 26 Oct 2009 19:49:25 -0700	[thread overview]
Message-ID: <4AE65FB5.3000905@gmail.com> (raw)
In-Reply-To: <7vocntd7vt.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
>
> If we are going to do this, wouldn't it make more sense to revert the
> rename of the script, so that people can keep relying on the name of the
> script being "git-completion.bash", _but_ make it produce a pre-compiled
> form to a separate file when invoked in some particular way?

Wouldn't relying on "git-completion.bash" to produce the pre-compiled
form cause problems if someone is running the build on a bash-less
system? I thought this issue was already raised by Shawn.

I guess we could ignore that issue now, and just say that you have to
build the pre-compiled form on systems with bash?

>
> Then at the runtime:
>
>  (0) If the script notices that it has already learned the command list
>      it uses it; otherwise,
>
>  (1) If the script notices that there is a file that contains the command
>      list, it sources it; otherwise,
>
>  (2) The script lazily builds the command list for its own use.
>
> And at the buildtime, Makefile can run the script in "generation mode",
> and install the output to where (1) above expects to see.

I assume you're suggesting this to ease the upgrade path for users. It
works nicely, we could just install the generated lists in the same path
(contrib/completion/) and then users would be free to copy the two files
anywhere as long as they're in the same directory. The only downside I
see is there's now two files, but that's ok with me.

  parent reply	other threads:[~2009-10-27  2:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-26 20:31 [PATCH 0/2] pre-generated completion fix and RFC Stephen Boyd
2009-10-26 20:31 ` [PATCH 1/2] completion: ignore custom merge strategies when pre-generating Stephen Boyd
2009-10-26 20:31 ` [PATCH/RFC 2/2] completion: allow use without compiling Stephen Boyd
2009-10-26 23:59   ` Junio C Hamano
2009-10-27  0:33     ` Clemens Buchacher
2009-10-27  0:38       ` Junio C Hamano
2009-10-28  8:19         ` Clemens Buchacher
2009-10-27  2:49     ` Stephen Boyd [this message]
2009-10-27 18:52   ` Shawn O. Pearce
2009-10-28  1:43     ` Stephen Boyd
2009-10-28  7:18       ` Junio C Hamano
2009-10-28  7:29         ` Stephen Boyd

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=4AE65FB5.3000905@gmail.com \
    --to=bebarino@gmail.com \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=spearce@spearce.org \
    --cc=srabbelier@gmail.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.