Re: [PATCH v2 00/41] Automate updating git-completion.bash a bit
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Feb 8, 2018, 12:05 UTC
- Message-ID
- <CACsJy8AJGr_5vjDGVp7h-2DbOvi3=uY3waoSm+Ko-muAuLxdoA@mail.gmail.com>
- In-Reply-To
- <xmqqr2pw7ge3.fsf@gitster-ct.c.googlers.com>
On Thu, Feb 8, 2018 at 2:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> 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 >> --<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. > > 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