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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> --<stuff> 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-avarab@xxxxxxxxx/

> parse-options: add OPT_xxx_F() variants

Not directly related to this series, but my own
https://public-inbox.org/git/20170324231013.23346-1-avarab@xxxxxxxxx/
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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux