{"thread":{"id":"48242","subject":"[RFC PATCH 0/1] completion: Dynamic completion loading","startedAt":"2018-04-08T18:26:17Z","lastAt":"2018-04-19T14:12:15Z","messageCount":13,"participants":["Florian Gamböck","Junio C Hamano","Stefan Beller","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"344110","messageId":"20180408182552.26289-1-mail@floga.de","threadId":"48242","inReplyTo":null,"subject":"[RFC PATCH 0/1] completion: Dynamic completion loading","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-08T18:26:07Z","receivedAt":"2018-04-08T18:26:17Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"In this small patch I want to introduce a way to dynamically load completion \nscripts for external subcommands.\n\nA few years ago, you would put a completion script (which defines a Bash \nfunction _git_foo for a custom git subcommand foo) into \n/etc/bash_completion.d, or save it somewhere in your $HOME and source it \nmanually in your .bashrc.\n\nStarting with bash-completion v2.0 (or, to be absolutely exact, the preview \nversions started at v1.90), completion scripts are not sourced at bash startup \nanymore. Rather, when typing in a command and trigger completion by pressing \nthe TAB key, the new bash-completion's main script looks for a script with the \nsame name as the typed command in the completion directory, sources it, and \nprovides the completions defined in this script.\n\nHowever, that only works for top level commands. After a completion script has \nbeen found, the logic is delegated to this script. This means, that the \ncompletion of subcommands must be handled by the corresponding completion \nscript.\n\nAs it is now, git is perfectly able to call custom completion functions, iff \nthey are already defined when calling the git completion. With my patch, git \nuses an already defined loader function of bash-completion (or continues \nsilently if this function is not found), loads an external completion script, \nand provides its completions.\n\nAn example for an external completion script would be \n/usr/share/bash-completion/completions/git-foo for a git subcommand foo.\n\nFlorian Gamböck (1):\n  completion: Load completion file for external subcommand\n\n contrib/completion/git-completion.bash | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\n-- \n2.16.1\n\n"},{"id":"344111","messageId":"20180408182552.26289-2-mail@floga.de","threadId":"48242","inReplyTo":"20180408182552.26289-1-mail@floga.de","subject":"[RFC PATCH 1/1] completion: Load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-08T18:26:08Z","receivedAt":"2018-04-08T18:26:21Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"Adding external subcommands to Git is as easy as to put an executable\nfile git-foo into PATH. Packaging such subcommands for a Linux\ndistribution can be achieved by unpacking the executable into /usr/bin\nof the user's system. Adding system-wide completion scripts for new\nsubcommands, however, can be a bit tricky.\n\nSince bash-completion started to use dynamical loading of completion\nscripts somewhere around v2.0, it is no longer sufficient to drop a\ncompletion script of a subcommand into the standard completions path,\n/usr/share/bash-completion/completions, since this script will not be\nloaded if called as a git subcommand.\n\nFor example, look at https://bugs.gentoo.org/544722. To give a short\nsummary: The popular git-flow subcommand provides a completion script,\nwhich gets installed as /usr/share/bash-completion/completions/git-flow.\n\nIf you now type into a Bash shell:\n\n    git flow <TAB>\n\nYou will not get any completions, because bash-completion only loads\ncompletions for git and git has no idea that git-flow is defined in\nanother file. You have to load this script manually or trigger the\ndynamic loader with:\n\n    git-flow <TAB> # Please notice the dash instead of whitespace\n\nThis will not complete anything either, because it only defines a Bash\nfunction, without generating completions. But now the correct completion\nscript has been loaded and the first command can use the completions.\n\nSo, the goal is now to teach the git completion script to consider the\npossibility of external completion scripts for subcommands, but of\ncourse without breaking current workflows.\n\nI think the easiest method is to use a function that is defined by\nbash-completion v2.0+, namely __load_completion. It will take care of\nloading the correct script if present. Afterwards, the git completion\nscript behaves as usual.\n\nThis way we can leverage bash-completion's dynamic loading for git\nsubcommands and make it easier for developers to distribute custom\ncompletion scripts.\n\nSigned-off-by: Florian Gamböck <mail@floga.de>\n---\n contrib/completion/git-completion.bash | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex b09c8a236..e6114822c 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -3096,12 +3096,20 @@ __git_main ()\n \tfi\n \n \tlocal completion_func=\"_git_${command//-/_}\"\n+\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n+\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n+\t\t\t__load_completion \"git-$command\"\n+\tfi\n \tdeclare -f $completion_func >/dev/null 2>/dev/null && $completion_func && return\n \n \tlocal expansion=$(__git_aliased_command \"$command\")\n \tif [ -n \"$expansion\" ]; then\n \t\twords[1]=$expansion\n \t\tcompletion_func=\"_git_${expansion//-/_}\"\n+\t\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n+\t\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n+\t\t\t\t__load_completion \"git-$expansion\"\n+\t\tfi\n \t\tdeclare -f $completion_func >/dev/null 2>/dev/null && $completion_func\n \tfi\n }\n-- \n2.16.1\n\n"},{"id":"344112","messageId":"20180408182552.26289-3-mail@floga.de","threadId":"48242","inReplyTo":"20180408182552.26289-1-mail@floga.de","subject":"[RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-08T18:26:13Z","receivedAt":"2018-04-08T18:26:23Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"Adding external subcommands to Git is as easy as to put an executable\nfile git-foo into PATH. Packaging such subcommands for a Linux\ndistribution can be achieved by unpacking the executable into /usr/bin\nof the user's system. Adding system-wide completion scripts for new\nsubcommands, however, can be a bit tricky.\n\nSince bash-completion started to use dynamical loading of completion\nscripts somewhere around v2.0, it is no longer sufficient to drop a\ncompletion script of a subcommand into the standard completions path,\n/usr/share/bash-completion/completions, since this script will not be\nloaded if called as a git subcommand.\n\nFor example, look at https://bugs.gentoo.org/544722. To give a short\nsummary: The popular git-flow subcommand provides a completion script,\nwhich gets installed as /usr/share/bash-completion/completions/git-flow.\n\nIf you now type into a Bash shell:\n\n    git flow <TAB>\n\nYou will not get any completions, because bash-completion only loads\ncompletions for git and git has no idea that git-flow is defined in\nanother file. You have to load this script manually or trigger the\ndynamic loader with:\n\n    git-flow <TAB> # Please notice the dash instead of whitespace\n\nThis will not complete anything either, because it only defines a Bash\nfunction, without generating completions. But now the correct completion\nscript has been loaded and the first command can use the completions.\n\nSo, the goal is now to teach the git completion script to consider the\npossibility of external completion scripts for subcommands, but of\ncourse without breaking current workflows.\n\nI think the easiest method is to use a function that is defined by\nbash-completion v2.0+, namely __load_completion. It will take care of\nloading the correct script if present. Afterwards, the git completion\nscript behaves as usual.\n\nThis way we can leverage bash-completion's dynamic loading for git\nsubcommands and make it easier for developers to distribute custom\ncompletion scripts.\n\nSigned-off-by: Florian Gamböck <mail@floga.de>\n---\n contrib/completion/git-completion.bash | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex b09c8a236..e6114822c 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -3096,12 +3096,20 @@ __git_main ()\n \tfi\n \n \tlocal completion_func=\"_git_${command//-/_}\"\n+\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n+\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n+\t\t\t__load_completion \"git-$command\"\n+\tfi\n \tdeclare -f $completion_func >/dev/null 2>/dev/null && $completion_func && return\n \n \tlocal expansion=$(__git_aliased_command \"$command\")\n \tif [ -n \"$expansion\" ]; then\n \t\twords[1]=$expansion\n \t\tcompletion_func=\"_git_${expansion//-/_}\"\n+\t\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n+\t\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n+\t\t\t\t__load_completion \"git-$expansion\"\n+\t\tfi\n \t\tdeclare -f $completion_func >/dev/null 2>/dev/null && $completion_func\n \tfi\n }\n-- \n2.16.1\n\n"},{"id":"344113","messageId":"20180408182907.GA28764@furore","threadId":"48242","inReplyTo":"20180408182552.26289-2-mail@floga.de","subject":"Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-08T18:29:07Z","receivedAt":"2018-04-08T18:29:13Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"Ah, sorry, please ignore this one.\n"},{"id":"344119","messageId":"xmqq37059uez.fsf@gitster-ct.c.googlers.com","threadId":"48242","inReplyTo":"20180408182552.26289-3-mail@floga.de","subject":"Re: [RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-08T22:59:16Z","receivedAt":"2018-04-08T22:59:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Florian Gamböck <mail@floga.de> writes:\n\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index b09c8a236..e6114822c 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -3096,12 +3096,20 @@ __git_main ()\n>  \tfi\n>  \n\nSorry if I am asking something obvious, as I am not fluent in\nbash-isms, but\n\n>  \tlocal completion_func=\"_git_${command//-/_}\"\n> +\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n> +\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n> +\t\t\t__load_completion \"git-$command\"\n\nwouldn't the above be easier to read if it were\n\n\tif ! declare ... $completion_func ... && declare -f __load_completion\n\tthen\n\t\t__load_completion \"git-$command\"\n\tfi\n\nor is there a reason why it is better to &&-chain the check for\n__load_completion with its use?  Same comment applies to the other\nhunk.\n"},{"id":"344159","messageId":"20180409072909.GA30684@arbeitsviech","threadId":"48242","inReplyTo":"xmqq37059uez.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-09T07:29:09Z","receivedAt":"2018-04-09T07:29:39Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"On 2018-04-09 07:59, Junio C Hamano wrote:\n> >  \tlocal completion_func=\"_git_${command//-/_}\"\n> > +\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n> > +\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n> > +\t\t\t__load_completion \"git-$command\"\n> \n> wouldn't the above be easier to read if it were\n> \n> \tif ! declare ... $completion_func ... && declare -f __load_completion\n> \tthen\n> \t\t__load_completion \"git-$command\"\n> \tfi\n> \n> or is there a reason why it is better to &&-chain the check for\n> __load_completion with its use?  Same comment applies to the other\n> hunk.\n\nGood point. I could go even further and ditch the if-construct:\n\n    ! declare -f $completion_func && declare -f __load_completion &&\n        __load_completion \"git-$command\"\n\nI originally intended to do a if-else-construct, which I re-thought\nhalfway through. I will change that in the next iteration.\n\nThank you!\n\n-- \nRegards\n\nFlorian\n"},{"id":"344186","messageId":"xmqqlgdw67rc.fsf@gitster-ct.c.googlers.com","threadId":"48242","inReplyTo":"20180409072909.GA30684@arbeitsviech","subject":"Re: [RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-09T09:36:55Z","receivedAt":"2018-04-09T09:37:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Florian Gamböck <mail@floga.de> writes:\n\n> Good point. I could go even further and ditch the if-construct:\n>\n>    ! declare -f $completion_func && declare -f __load_completion &&\n>        __load_completion \"git-$command\"\n\nI personally find that a lot harder to read than if/then/fi.\n"},{"id":"344191","messageId":"20180409133627.GA25078@arbeitsviech","threadId":"48242","inReplyTo":"xmqqlgdw67rc.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-09T13:36:27Z","receivedAt":"2018-04-09T13:36:57Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"On 2018-04-09 18:36, Junio C Hamano wrote:\n> Florian Gamböck <mail@floga.de> writes:\n> \n> > Good point. I could go even further and ditch the if-construct:\n> >\n> >    ! declare -f $completion_func && declare -f __load_completion &&\n> >        __load_completion \"git-$command\"\n> \n> I personally find that a lot harder to read than if/then/fi.\n\nThen I mis-understood you the first time. It sounded a bit as if you\nwanted to avoid if-fi. After all, the rest of this code block also uses\nquite long &&-chains.\n\nThen we are back at the first question:\n\n> >  \tlocal completion_func=\"_git_${command//-/_}\"\n> > +\tif ! declare -f $completion_func >/dev/null 2>/dev/null; then\n> > +\t\tdeclare -f __load_completion >/dev/null 2>/dev/null &&\n> > +\t\t\t__load_completion \"git-$command\"\n> \n> wouldn't the above be easier to read if it were\n> \n> \tif ! declare ... $completion_func ... && declare -f __load_completion\n> \tthen\n> \t\t__load_completion \"git-$command\"\n> \tfi\n> \n> or is there a reason why it is better to &&-chain the check for\n> __load_completion with its use?\n\nAs for readability, I would prefer my first approach then with the\nfollowing reasoning: Checking the existence of a function and actually\ncalling it can be seen as a unit. Either the function does not exist or\nyou call it. You could even create a function like \"call_if_exists\",\nthat does exactly this. Either way, at the end of the line you are\nsmarter than before. As for the if-statement, this describes the reason\nwhy you even want to load an external file. If the function in question\n($completion_func) already exists, we do not want to load it again. If\nyou chain the statement with the existence check of __load_completion,\nyou make it look like those two functions are somehow related, which is\nnot the case.\n\nTo put it in words: \"If $completion_func does not already exist, then\nload another file (if you know how to do that).\" versus \"If\n$completion_func does not yet exist and you know how to load another\nfile, then load another file.\" The difference is subtle, but I think the\nfirst sentence better describes the intention.\n\nDoes my reasoning make sense? I mean, the result will be exactly the\nsame, we are clearly only talking about readability here.\n"},{"id":"344222","messageId":"CAGZ79kZzMDjKzuHn5ph+zMkh_9Zt_at37MssOjHvzJndUjt9yQ@mail.gmail.com","threadId":"48242","inReplyTo":"20180408182552.26289-2-mail@floga.de","subject":"Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-04-09T18:26:05Z","receivedAt":"2018-04-09T18:26:11Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Sun, Apr 8, 2018 at 11:26 AM, Florian Gamböck <mail@floga.de> wrote:\n> Adding external subcommands to Git is as easy as to put an executable\n> file git-foo into PATH. Packaging such subcommands for a Linux\n> distribution can be achieved by unpacking the executable into /usr/bin\n> of the user's system. Adding system-wide completion scripts for new\n> subcommands, however, can be a bit tricky.\n>\n> Since bash-completion started to use dynamical loading of completion\n> scripts somewhere around v2.0, it is no longer sufficient to drop a\n> completion script of a subcommand into the standard completions path,\n> /usr/share/bash-completion/completions, since this script will not be\n> loaded if called as a git subcommand.\n\nAlso v1.90 here? (hint from the cover letter, please be exact)\n\nIf Gits own completion script would be broken up by subcommand,\nwould that also deliver an improvement in performance?\n\nThanks,\nStefan\n"},{"id":"344230","messageId":"20180409194955.GA22994@furore","threadId":"48242","inReplyTo":"CAGZ79kZzMDjKzuHn5ph+zMkh_9Zt_at37MssOjHvzJndUjt9yQ@mail.gmail.com","subject":"Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"ml@floga.de","sentAt":"2018-04-09T19:49:55Z","receivedAt":"2018-04-09T19:50:03Z","isPatch":true,"sender":{"key":"ml@floga.de","avatar":null},"body":"On 2018-04-09 11:26, Stefan Beller wrote:\n>> Since bash-completion started to use dynamical loading of completion \n>> scripts somewhere around v2.0, it is no longer sufficient to drop a \n>> completion script of a subcommand into the standard completions path, \n>> /usr/share/bash-completion/completions, since this script will not be \n>> loaded if called as a git subcommand.\n>\n> Also v1.90 here? (hint from the cover letter, please be exact)\n\nYes, it started at 1.90. I will reword the commit message and be more \nexact in the next iteration.\n\n> If Gits own completion script would be broken up by subcommand, would \n> that also deliver an improvement in performance?\n\nAs it is now, the completion script is quite big. On a system with \nlimited resources, the initial loading time can be long and the memory \nfootprint is big, given that most users will just use a few commands. If \nyou just use the \"commit\" subcommand, the first loading of the two \n(smaller) scripts will be slightly longer the first time (but not as \nlong as with one big script, I think), but the footprint will be \ndrastically lower. The whole script is 56kB big (without comments), \nafter radically removing everything which is not connected to \n_git_commit, it is only 11kB.\n\nSo to answer your question: Yes. My first intuition is, that by \nsplitting the completion script and loading the sub-scripts dynamically, \nit will improve in terms of speed and overall memory footprint, at least \nfor the average user that does not fire up all possible git commands.\n\n-- \nRegards\n\nFlorian\n"},{"id":"344251","messageId":"xmqq8t9w591b.fsf@gitster-ct.c.googlers.com","threadId":"48242","inReplyTo":"20180409133627.GA25078@arbeitsviech","subject":"Re: [RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-09T22:06:56Z","receivedAt":"2018-04-09T22:07:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Florian Gamböck <mail@floga.de> writes:\n\n> On 2018-04-09 18:36, Junio C Hamano wrote:\n>> Florian Gamböck <mail@floga.de> writes:\n>>\n>> > Good point. I could go even further and ditch the if-construct:\n>> >\n>> >    ! declare -f $completion_func && declare -f __load_completion &&\n>> >        __load_completion \"git-$command\"\n>>\n>> I personally find that a lot harder to read than if/then/fi.\n> ...\n> Does my reasoning make sense?\n\nNot at all.  But ...\n\n> I mean, the result will be exactly the same, we are clearly only\n> talking about readability here.\n\n... I agree, and I also think the \"readability\" is not absolute\nanyway.\n\nFWIW, personally I'd find \"if $completion_func does not yet exist\nand a way to dynload stuff exists, then use that way to load it from\nan external file\" the most natural way to express what you are\ndoing.\n\n"},{"id":"344307","messageId":"20180410093749.GA8706@arbeitsviech","threadId":"48242","inReplyTo":"xmqq8t9w591b.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH 1/1] completion: load completion file for external subcommand","fromName":"Florian Gamböck","fromEmail":"mail@floga.de","sentAt":"2018-04-10T09:37:49Z","receivedAt":"2018-04-10T09:38:24Z","isPatch":true,"sender":{"key":"mail@floga.de","avatar":"https://avatars.githubusercontent.com/u/633683?v=4"},"body":"On 2018-04-10 07:06, Junio C Hamano wrote:\n> Florian Gamböck <mail@floga.de> writes:\n>> Does my reasoning make sense?\n>\n> Not at all.\n\n:-( That actually hurt a bit.\n\n> But ...\n>\n>> I mean, the result will be exactly the same, we are clearly only \n>> talking about readability here.\n>\n> ... I agree, and I also think the \"readability\" is not absolute \n> anyway.\n>\n> FWIW, personally I'd find \"if $completion_func does not yet exist and \n> a way to dynload stuff exists, then use that way to load it from an \n> external file\" the most natural way to express what you are doing.\n\nThen let's go with that. Maybe I am overthinking things here and \nre-wording doesn't hurt.\n\nI'll send a new patch version later this day, including the commit \nmessage re-wording suggestion from Stefan.\n\nThank you for your feedback!\n\n-- \nRegards\n\nFlorian\n"},{"id":"345112","messageId":"CAM0VKjn3PQoXDStgB2_s2QQWeL8Z7e4UbrYMGPou0kdnXpfYwQ@mail.gmail.com","threadId":"48242","inReplyTo":"20180409194955.GA22994@furore","subject":"Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-04-19T14:12:09Z","receivedAt":"2018-04-19T14:12:15Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Apr 9, 2018 at 9:49 PM, Florian Gamböck <ml@floga.de> wrote:\n> On 2018-04-09 11:26, Stefan Beller wrote:\n>> If Gits own completion script would be broken up by subcommand, would that\n>> also deliver an improvement in performance?\n>\n>\n> As it is now, the completion script is quite big. On a system with limited\n> resources, the initial loading time can be long and the memory footprint is\n> big, given that most users will just use a few commands. If you just use the\n> \"commit\" subcommand, the first loading of the two (smaller) scripts will be\n> slightly longer the first time (but not as long as with one big script, I\n> think), but the footprint will be drastically lower. The whole script is\n> 56kB big (without comments), after radically removing everything which is\n> not connected to _git_commit, it is only 11kB.\n>\n> So to answer your question: Yes. My first intuition is, that by splitting\n> the completion script and loading the sub-scripts dynamically, it will\n> improve in terms of speed and overall memory footprint, at least for the\n> average user that does not fire up all possible git commands.\n\nWhile \"most users\" might indeed only use a couple of git commands,\nthey don't use systems so limited in resources where 56k vs. 11k makes\na non-negligible difference.  A system, where such a small difference\nis significant, must be so thight on resources that the user will most\nlikely have issues running git anyway.\n\nI don't know how much memory Bash uses to store completion scripts,\nand it appears to be using a memory pool or something like our\nALLOC_GROW, making measuring its memory footprint with simple means\nunusably inaccurate.  Anyway, here are some numbers:\n\n  # Baseline, bash does nothing:\n  $ command time -f %M bash -c ''\n  2924\n\n  # Loading a <10k script:\n  $ wc -c ./git-sh-setup.sh\n  9313 ./git-sh-setup.sh\n  command time -f %M bash -c '. ./git-sh-setup.sh'\n  3724\n\n  # Loading our completion script; the increase in max memory\n  # footprint is clearly not proportional to the size of the loaded\n  # script:\n  $ wc -c ./contrib/completion/git-completion.bash\n  69413 ./contrib/completion/git-completion.bash\n  $ command time -f %M bash -c '. ./contrib/completion/git-completion.bash'\n  4092\n\n  # The main bash-completion script, though slightly smaller than ours,\n  # appears to be requiring much more memory:\n  $ wc -c /usr/share/bash-completion/bash_completion\n  67661 /usr/share/bash-completion/bash_completion\n  $ command time -f %M bash -c './usr/share/bash-completion/bash_completion'\n  5952\n\n  # Loading both the main bash-completion script and our completion\n  # script, which is where that memory pool/ALLOC_GROW-like thingy really\n  # kicks in, as there is no real max memory footprint increase:\n  $ command time -f %M bash -c '. /usr/share/bash-completion/bash_completion\n                                . ./contrib/completion/git-completion.bash'\n  5964\n\n\nOTOH, our completion script has a couple of nice properties that we\nshould keep working:\n\n  - A user can simply run '. /path/to/git-completion.bash', and then\n    completion for git commands will work.  Even without\n    bash-completion package, even in 'bash --norc'.\n\n    If we were to split up our completion script, we would also have\n    to roll our own __git_load_completion() funcion.\n\n  - A user building Git from source doesn't have to install the\n    completion script, it can be sourced from anywhere.  And if the\n    user chooses to install it somewhere, only a single file has to be\n    copied.\n\n    Currently we have completion functions for 55 git commands, which\n    would mean 56 files to install if the completion script were split\n    up.\n\n  - Sourcing 'git-completion.bash' brings in all the latest and\n    greatest.\n\n    If it were split up, then sourcing it would only update the common\n    functions, but not the completion functions of individual git\n    commands.  So we would have to take extra steps to delete those\n    command-specific completion functions upon sourcing the completion\n    script.  However, we should be extra careful to delete only those\n    completion functions that were source by the completion script,\n    because users might have defined such functions in their\n    '~/.bashrc'...\n\n\nI don't think it's worth it.\n"}]}