Thread (115 messages) flat view 115 messages, 4 authors, 2018-12-11

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

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2018-01-31 15:01:16

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@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-avarab@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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help