Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can b
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can b
Ah, sorry, please ignore this one.
Florian Gamböck writes:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index b09c8a236..e6114822c 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -3096,12 +3096,20 @@ __git_main ()
>
On 2018-04-09 07:59, Junio C Hamano wrote:
>local completion_func="_git_${command//-/_}"
> + if ! declare -f $completion_func >/dev/null 2>/dev/null; then
> + declare -f __load_completion >/dev/null 2>/dev/null &&
> + __load_completion "git-$command"
wouldn't the a
Florian Gamböck writes:
> Good point. I could go even further and ditch the if-construct:
>
>! declare -f $completion_func && declare -f __load_completion &&
>__load_completion "git-$command"
I personally find that a lot harder to read than if/then/fi.
On 2018-04-09 18:36, Junio C Hamano wrote:
Florian Gamböck writes:
> Good point. I could go even further and ditch the if-construct:
>
>! declare -f $completion_func && declare -f __load_completion &&
>__load_completion "git-$command"
I personally find that a lot harder to read tha
On Sun, Apr 8, 2018 at 11:26 AM, Florian Gamböck wrote:
> Adding external subcommands to Git is as easy as to put an executable
> file git-foo into PATH. Packaging such subcommands for a Linux
> distribution can be achieved by unpacking the executable into /usr/bin
> of the user's system. Adding s
On 2018-04-09 11:26, Stefan Beller wrote:
Since bash-completion started to use dynamical loading of completion
scripts somewhere around v2.0, it is no longer sufficient to drop a
completion script of a subcommand into the standard completions path,
/usr/share/bash-completion/completions, since
Florian Gamböck writes:
> On 2018-04-09 18:36, Junio C Hamano wrote:
>> Florian Gamböck writes:
>>
>> > Good point. I could go even further and ditch the if-construct:
>> >
>> >! declare -f $completion_func && declare -f __load_completion &&
>> >__load_completion "git-$command"
>>
>>
On 2018-04-10 07:06, Junio C Hamano wrote:
Florian Gamböck writes:
Does my reasoning make sense?
Not at all.
:-( That actually hurt a bit.
But ...
I mean, the result will be exactly the same, we are clearly only
talking about readability here.
... I agree, and I also think the "readab
On Mon, Apr 9, 2018 at 9:49 PM, Florian Gamböck wrote:
> On 2018-04-09 11:26, Stefan Beller wrote:
>> If Gits own completion script would be broken up by subcommand, would that
>> also deliver an improvement in performance?
>
>
> As it is now, the completion script is quite big. On a system with l
12 matches
Mail list logo
