mbox series

[v2,0/5] completion: remove hardcoded config variable names

Message ID pull.1660.v2.git.git.1706534881.gitgitgadget@gmail.com (mailing list archive)
Headers show
Series completion: remove hardcoded config variable names | expand

Message

Derrick Stolee via GitGitGadget Jan. 29, 2024, 1:27 p.m. UTC
Changes since v1:

 * Corrected my email in PATCH 2/5 (sorry for the noise)

v1: This series removes hardcoded config variable names in the
__git_complete_config_variable_name function, partly by adding a new mode to
'git help'. It also adds completion for 'submodule.*' config variables,
which were previously missing.

I think it makes sense to do that in the same series since it's closely
related, and splitting it would result in textual conflicts between both
series if one does not build on top of the other, but I'm open to other
suggestions.

Thanks,

Philippe.

Philippe Blain (5):
  completion: add space after config variable names also in Bash 3
  completion: complete 'submodule.*' config variables
  completion: add and use
    __git_compute_first_level_config_vars_for_section
  builtin/help: add --config-all-for-completion
  completion: add an use
    __git_compute_second_level_config_vars_for_section

 builtin/help.c                         |  7 ++
 contrib/completion/git-completion.bash | 90 +++++++++++++-------------
 t/t9902-completion.sh                  | 21 ++++++
 3 files changed, 74 insertions(+), 44 deletions(-)


base-commit: b50a608ba20348cb3dfc16a696816d51780e3f0f
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1660%2Fphil-blain%2Fcompletion-submodule-config-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1660/phil-blain/completion-submodule-config-v2
Pull-Request: https://github.com/git/git/pull/1660

Range-diff vs v1:

 1:  837d92a6c27 = 1:  837d92a6c27 completion: add space after config variable names also in Bash 3
 2:  2dd3085f8d8 ! 2:  426374ff9b3 completion: complete 'submodule.*' config variables
     @@
       ## Metadata ##
     -Author: Philippe Blain <philippe.blain@canada.ca>
     +Author: Philippe Blain <levraiphilippeblain@gmail.com>
      
       ## Commit message ##
          completion: complete 'submodule.*' config variables
 3:  dd9395bda32 = 3:  838aabf2858 completion: add and use __git_compute_first_level_config_vars_for_section
 4:  3e83f21eb4e = 4:  d442a039b27 builtin/help: add --config-all-for-completion
 5:  b41844cd86e = 5:  a2e792c911e completion: add an use __git_compute_second_level_config_vars_for_section

Comments

Junio C Hamano Feb. 7, 2024, 10:08 p.m. UTC | #1
"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Changes since v1:
>
>  * Corrected my email in PATCH 2/5 (sorry for the noise)
>
> v1: This series removes hardcoded config variable names in the
> __git_complete_config_variable_name function, partly by adding a new mode to
> 'git help'. It also adds completion for 'submodule.*' config variables,
> which were previously missing.
>
> I think it makes sense to do that in the same series since it's closely
> related, and splitting it would result in textual conflicts between both
> series if one does not build on top of the other, but I'm open to other
> suggestions.
>
> Thanks,

Neither rounds of this series unfortunately got any review.
Comments from anybody interested in helping to improve completion
scripts?

Thanks.
Patrick Steinhardt Feb. 8, 2024, 7:42 a.m. UTC | #2
On Wed, Feb 07, 2024 at 02:08:07PM -0800, Junio C Hamano wrote:
> "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > Changes since v1:
> >
> >  * Corrected my email in PATCH 2/5 (sorry for the noise)
> >
> > v1: This series removes hardcoded config variable names in the
> > __git_complete_config_variable_name function, partly by adding a new mode to
> > 'git help'. It also adds completion for 'submodule.*' config variables,
> > which were previously missing.
> >
> > I think it makes sense to do that in the same series since it's closely
> > related, and splitting it would result in textual conflicts between both
> > series if one does not build on top of the other, but I'm open to other
> > suggestions.
> >
> > Thanks,
> 
> Neither rounds of this series unfortunately got any review.
> Comments from anybody interested in helping to improve completion
> scripts?

Well, I've spent some time with Bash completion recently, so let me give
it a go. I was trying to avoid the dense Bash logic and thus shied away
from reviewing it. But the end result of having less hardcoded values is
quite nice indeed.

Patrick