Re: [PATCH v2 00/41] Automate updating git-completion.bash a bit

[Duy Nguyen]

On Thu, Feb 8, 2018 at 2:23 AM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> I posted a proof of concept a while back [1]. This is the full version.
>>
>> This series lets "git" binary help git-completion.bash to complete
>> -- so that when a new option is added, we don't have to update
>> git-completion.bash manually too (people often forget it). As a side
>> effect, about 180 more options are now completable.
>>
>> parse-options is updated to allow developers to flag certain options
>> not to be completable if they want finer control over it.  But by
>> default, new non-hidden options are completable. Negative forms must
>> be handled manually. That's for the next step.
>
> Everybody seems to be in favour of the approach taken by this
> series.  Is it in a good enough shape that we can merge it to 'next'
> and then go incremental from now on?

Not until v3. v2 breaks Mac OS because I used some fancy bash feature.
There are some good improvements in __gitcomp_builtin() suggested by
Eric and Szeder, which will be in v3 as well.

> Or do we want to keep it in
> 'pu' to give easier access to volunteer guinea pigs and wait until
> the way to handle '--no-foo' options are figured out?

Oh the --no-foo thing is definitely not part of this version. Once
this series lands though, people can start improving --no-foo per
command, even in parallel. "git foo -h" will also benefit from that
effort because we will be able to show --no- form only when we mean to
allow --no-.
-- 
Duy

Re: [PATCH v2 00/41] Automate updating git-completion.bash a bit

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> I posted a proof of concept a while back [1]. This is the full version.
>
> This series lets "git" binary help git-completion.bash to complete
> -- so that when a new option is added, we don't have to update
> git-completion.bash manually too (people often forget it). As a side
> effect, about 180 more options are now completable.
>
> parse-options is updated to allow developers to flag certain options
> not to be completable if they want finer control over it.  But by
> default, new non-hidden options are completable. Negative forms must
> be handled manually. That's for the next step.

Everybody seems to be in favour of the approach taken by this
series.  Is it in a good enough shape that we can merge it to 'next'
and then go incremental from now on?  Or do we want to keep it in
'pu' to give easier access to volunteer guinea pigs and wait until
the way to handle '--no-foo' options are figured out?

Re: [PATCH v2 00/41] Automate updating git-completion.bash a bit

[Ævar Arnfjörð Bjarmason]

On Wed, Jan 31 2018, Nguyễn Thái Ngọc Duy jotted:

> I posted a proof of concept a while back [1]. This is the full version.
>
> This series lets "git" binary help git-completion.bash to complete
> -- so that when a new option is added, we don't have to update
> git-completion.bash manually too (people often forget it). As a side
> effect, about 180 more options are now completable.
>
> parse-options is updated to allow developers to flag certain options
> not to be completable if they want finer control over it.  But by
> default, new non-hidden options are completable. Negative forms must
> be handled manually. That's for the next step.
>
> The number of patches is high, but changes after the first four
> patches and 33/41 are quite simple. I still need some eyeballs though
> to make sure I have not accidentally allowed completion of dangerous
> options. Details are broken down per command in each commit message.
>
> If people want to play with this, I have a script [2] that shows all
> completable options for most commands (I ignore some that are
> shell-based because I don't touch them in this series). You can then
> do a "diff" to see new/old options.

Thanks, looks great to me, especially caching the result of the
completion.

> There's a small conflict with 'pu' because --prune-tags is added in
> git-completion.bash. The solution is simple and beautiful: ignore
> those changes, --prune-tags will be completable anyway :)

Yay! Also another good argument for this series, it took me until v3
until I noticed I'd forgotten the bash completion:
https://public-inbox.org/git/20180123221326.28495-1-ava...@gmail.com/

> parse-options: add OPT_xxx_F() variants

Not directly related to this series, but my own
https://public-inbox.org/git/20170324231013.23346-1-ava...@gmail.com/
which I've been meaning to clean up and re-submit also added some new
macros to this file.

I've been wondering what a good solution is to avoid a combinatorial
explosion explosion of these macros in the longer term, but haven't come
up with anthing.

[PATCH v2 00/41] Automate updating git-completion.bash a bit

[Nguyễn Thái Ngọc Duy]

I posted a proof of concept a while back [1]. This is the full version.

This series lets "git" binary help git-completion.bash to complete
-- so that when a new option is added, we don't have to update
git-completion.bash manually too (people often forget it). As a side
effect, about 180 more options are now completable.

parse-options is updated to allow developers to flag certain options
not to be completable if they want finer control over it.  But by
default, new non-hidden options are completable. Negative forms must
be handled manually. That's for the next step.

The number of patches is high, but changes after the first four
patches and 33/41 are quite simple. I still need some eyeballs though
to make sure I have not accidentally allowed completion of dangerous
options. Details are broken down per command in each commit message.

If people want to play with this, I have a script [2] that shows all
completable options for most commands (I ignore some that are
shell-based because I don't touch them in this series). You can then
do a "diff" to see new/old options.

There's a small conflict with 'pu' because --prune-tags is added in
git-completion.bash. The solution is simple and beautiful: ignore
those changes, --prune-tags will be completable anyway :)

[1] https://public-inbox.org/git/%3c20180116103700.4505-1-pclo...@gmail.com%3E/
[2] https://gist.github.com/pclouds/f337d4393b5cfab813909b8eea2eaa40

Nguyễn Thái Ngọc Duy (41):
  parse-options: support --git-completion-helper
  parse-options: add OPT_xxx_F() variants
  parse-options: let OPT__FORCE take optional flags argument
  git-completion.bash: introduce __gitcomp_builtin
  completion: use __gitcomp_builtin in _git_add
  completion: use __gitcomp_builtin in _git_am
  completion: use __gitcomp_builtin in _git_apply
  completion: use __gitcomp_builtin in _git_branch
  completion: use __gitcomp_builtin in _git_checkout
  completion: use __gitcomp_builtin in _git_cherry_pick
  completion: use __gitcomp_builtin in _git_clean
  completion: use __gitcomp_builtin in _git_clone
  completion: use __gitcomp_builtin in _git_commit
  completion: use __gitcomp_builtin in _git_config
  completion: use __gitcomp_builtin in _git_describe
  completion: use __gitcomp_builtin in _git_difftool
  completion: use __gitcomp_builtin in _git_fetch
  completion: use __gitcomp_builtin in _git_fsck
  completion: use __gitcomp_builtin in _git_gc
  completion: use __gitcomp_builtin in _git_grep
  completion: use __gitcomp_builtin in _git_help
  completion: use __gitcomp_builtin in _git_init
  completion: use __gitcomp_builtin in _git_ls_files
  completion: use __gitcomp_builtin in _git_ls_remote
  completion: use __gitcomp_builtin in _git_merge
  completion: use __gitcomp_builtin in _git_merge_base
  completion: use __gitcomp_builtin in _git_mv
  completion: use __gitcomp_builtin in _git_name_rev
  completion: use __gitcomp_builtin in _git_notes
  completion: use __gitcomp_builtin in _git_pull
  completion: use __gitcomp_builtin in _git_push
  completion: use __gitcomp_builtin in _git_remote
  remote: force completing --mirror= instead of --mirror
  completion: use __gitcomp_builtin in _git_replace
  completion: use __gitcomp_builtin in _git_reset
  completion: use __gitcomp_builtin in _git_revert
  completion: use __gitcomp_builtin in _git_rm
  completion: use __gitcomp_builtin in _git_show_branch
  completion: use __gitcomp_builtin in _git_status
  completion: use __gitcomp_builtin in _git_tag
  completion: use __gitcomp_builtin in _git_worktree

 apply.c|   5 +-
 builtin/add.c  |   2 +-
 builtin/am.c   |  16 +-
 builtin/branch.c   |   2 +-
 builtin/checkout-index.c   |   2 +-
 builtin/checkout.c |   7 +-
 builtin/clean.c|   2 +-
 builtin/fetch.c|   2 +-
 builtin/gc.c   |   7 +-
 builtin/grep.c |  13 +-
 builtin/ls-remote.c|   5 +-
 builtin/mv.c   |   3 +-
 builtin/notes.c|   4 +-
 builtin/pull.c |   2 +-
 builtin/push.c |   2 +-
 builtin/remote.c   |   2 +-
 builtin/replace.c  |   3 +-
 builtin/revert.c   |  12 +-
 builtin/rm.c   |   2 +-
 builtin/tag.c  |   2 +-
 builtin/update-server-info.c   |   2 +-
 builtin/worktree.c |   4 +-
 contrib/completion/git-completion.bash | 276 +
 parse-options.c|  46 +
 parse-options.h|  40 ++--
 rerere.h   |   3 +-
 t/t9902-completion.sh  |  12 +-
 27 files changed, 236 insertions(+), 242 deletions(-)

-- 
2.16.1.205.g271f633410