dgit has a number of rather long option names (for example though not
limited to the --deliberately-* family).  Having to type these out by
hand makes me wish for bash completion support, similar to the generally
excellent completion provided by git itself, so that I could
tab-complete option names.

I'm aware that writing shell completion files is sometimes a rather
open-ended task, so for the purposes of this bug I'm just requesting
completion over options.

Thanks,

Colin Watson writes ("Bug#928704: dgit: add bash completion for command-line options"):

This is a fine idea.

However I don't use bash-completion because I personally find it
annoying, and I have no idea how to do this.  I would welcome
contributions, even in the form of a skeleton or initial version which
I could keep up to date.

Thanks,
Ian.

Yes, I'm afraid that while I use it and (with some exceptions) generally
like it, I have never actually rolled up my sleeves and worked out how
to write the things myself, so this would be a learning curve for me
too.  It'll go on my to-do list somewhere but quite a long way down, so
if anyone else wants to tackle it then that might be better ...

I believe that in general terms the two strategies are to enumerate all
the possible options separately or to have some way to ask the program
which options it supports.  The bash-completion file for git appears to
take the former strategy for the relatively small number of options
supported by the top-level git program, and the latter strategy for git
subcommands (see e.g. "git checkout --git-completion-helper").

Thanks,

Colin Watson writes ("Re: Bug#928704: dgit: add bash completion for command-line options"):

In the case of dgit, the command line parser is not table driven
(although it does have some tables) so the latter strategy won't work.

But I think the option parser perl code could be scanned by some
ad-hoc perl code, at package build time.  It's mostly quite formulaic.

I can probably implement something like that, given a hand-coded
completion file (perhaps a partial one) and someone to ask questions.

Ian.

Hi,

I’m attaching a bash completion script which performs completion for many, but
not all options and commands.

Specifically, it autocompletes the most common subcommands, but only provides
arguments autocompletion for only two of them, import-dsc and rpush, for
practical reasons.

For dgit options, it provides two-level completion for the most popular options,
excluding rarely used or dangerous ("use when you know what you’re doing") options.
The two-levels work in a way to not overwhelm the user with options when they Tab
twice, so only some but not all arguments to e.g. --quilt= are shown:

$ dgit --
--baredebian                                 --force-import-gitapply-no-absurd
--baredebian+git                             --force-reusing-version
--baredebian+tarball                         --force-unrepresentable
--build-products-dir=                        --force-unsupported-source-format
--clean                                      --force-uploading-binaries
--clean=dpkg-source                          --force-uploading-source-only
--clean=git                                  --gbp
--clean=git-ff                               --include-dirty
--damp-run                                   --new
--delayed=                                   --no-rm-on-error
--deliberately-fresh-repo                    --no-sign
--deliberately-include-questionable-history  --overwrite
--deliberately-not-fast-forward              --package
--dep14tag                                   --quilt
--distro=                                    --quilt=auto
--dpm                                        --quilt=linear
--dry-run                                    --rm-old-changes
--force-changes-origs-exactly                --save-dgit-view=
--force-dsc-changes-mismatch                 --split-view=
--force-import-dsc-with-dgit-field           --upstream-commitish=
--force-import-gitapply-absurd               

However, when the user types --quilt=, the rest of them is shown:

$ dgit --quilt=
auto            baredebian+git      dpm      linear       nofix      unapplied
baredebian      baredebian+tarball  gbp      nocheck      smash

For --upstream-commitish= the script autocompletes some tags, starting with tags
with the matching version, and the rest sorted by version:

$ dgit --upstream-commitish=upstream/1.
upstream/1.11.0  upstream/1.6.0

For options accepting both = and space (--quilt, --clean, --package) the completion
is performed for both versions; the list of all options above shows the "spaced" (--clean)
version and a couple of commonly used versions with = and an argument. For options
only accepting =, the option ends with = to allow the user to start typing the argument
directly after that.

Hi Ian,

Is there anything I can do to help you with this? I also considered
submitting the script to the bash-completion project, but it seems
they’d have preferred if dgit shipped it rather them.

Andrej Shadura writes ("Bug#928704: dgit: add bash completion for command-line options"):

I agree that it would better live in src:dgit.

But I have a concern about how to keep it up to date.  That's why I
suggested autogenerating it from the option parser.

However, I looked at the attachment
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=928704;filename=dgit_completion;msg=27
and well, I'm really not sure I can do something sane to generate
that from the source code.

Do you have any suggestions ?  Surely users of bash completion[1]
wouldn't like it if new options didn't autocomplete just because the
completions hadn't been updated.

Ian.

[1] This generally doesn't include me precisely because IME things
often turn out not to complete properly.  So maybe I am being too
precious.