On Mon, Oct 26, 2009 at 05:38:10PM -0700, Junio C Hamano wrote: > Clemens Buchacher <drizzd@xxxxxx> writes: > > > On Mon, Oct 26, 2009 at 04:59:18PM -0700, Junio C Hamano wrote: > > > >> Stephen Boyd <bebarino@xxxxxxxxx> writes: > >> > >> > This duplicates code, but I don't know of a way to re-use the dynamic > >> > code without sourcing a bash script and possibly breaking someone's build. > >> > >> (1) If the script notices that there is a file that contains the command > >> list, it sources it; otherwise, > > > > Or we substitute the command list in-place, so that we still have the entire > > completion script in one file. > > That defeats the whole point of my suggestion, as you would be overwriting > the tracked file. Ok, not in-place then. What I meant is something like this. git-completion.bash.in: completion script with placeholders for command list generation code and static command list git-command-list.sh: bash-agnostic command list generation script git-completion.bash.generate: run git-command-list.sh and replace static command list placeholder in git-completion.bash.in, also insert command list generation code into git-completion.bash.in, write result to git-completion.bash Whether or not the command list should be loaded dynamically can be decided on a per-user basis using a configuration option. A downside of this approach is that even if we do not need the static command list, we still need to generate the completion script. I therefore recommend we make this part of the normal build process. Alternatively, we could source the command list code. But it's inconvenient to copy two completion scripts and it will probably cause confusion among users. Clemens -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html