Thread (10 messages) flat view 10 messages, 3 authors, 2016-06-15

Re: [PATCH] Speedup bash completion loading

From: Kirill Smelkov <hidden>
Date: 2016-06-15 22:47:29

Possibly related (same subject, not in this thread)

On Thu, Oct 08, 2009 at 08:02:06AM -0700, Shawn O. Pearce wrote:
Kirill Smelkov [off-list ref] wrote:
quoted
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.
quoted
+# 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.
Agree with everything and thanks. Will reroll tommorow.

Кирилл
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help