On Mon, Jun 24, 2019 at 12:22 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > > On Sat, Jun 22, 2019 at 5:31 AM Felipe Contreras > > <felipe.contreras@xxxxxxxxx> wrote: > >> > >> Versions of Git older than v2.17 don't know about > >> --git-completion-helper, so provide some defaults for them. > > ... > >> +__gitcomp_builtin_add_default=" --dry-run --verbose --interactive --patch --edit --force --update --renormalize --intent-to-add --all --ignore- > > removal --refresh --ignore-errors --ignore-missing --chmod= > > --no-dry-run -- --no-verbose --no-interactive --no-patch --no-edit > > --no-force --no-update --no-renormalize --no-intent-to-add --no-all > > --no-ignore-removal --no-refresh --no-ignore-errors > > --no-ignore-missing --no-chmod" > > > > And who's going to keep these uptodate? If you do this, might as well > > delete --git-completion-helper > > > > A more acceptable option might be regenerate git-completion.bash and > > run --git-completion-helper to generate these, or make > > git-completion.bash source a generated file. > > Nicely analysed and summarized. What kind of target audience are we > talking about? The people that install their completion independently of their distribution. A quick search in Stack Overflow shows hundreds of questions, many related to Homebrew and Cygwin. > What's the payoff vs cost comparison trying to > catering to those who install more recent completion script that > requires the --git-completion-helper option without using antient > Git? You use the adjective "ancient", but is it really? The current Ubuntu LTS release uses 2.17.1, the previous one (supported until 2021) uses 2.7.4, the current Debian stable uses 2.11.0, and the previous RHEL uses 2.3.5. Travis CI runs 2.15.1 by default. If you are going to call these "ancient" what would you call the current version in Debian oldstable? 2.1.4. Not everyone is a privileged as us. > If the cutoff boundary is 2.17, that is more than year ago, and the > boundary gets further and further in the past as time goes by. Also, > depending on how old the version of Git the target user runs, these > hardcoded and manually listed options may not yet even exist in > their binary. Indeed, the need for these defaults will diminish over time, but *right now* people are running versions of Git older than 2.17, for sure. And yes, it's possible that the completion will return an option that doesn't exist yet in the user's version of Git, but historically that has always been the case regarding Git completions (at least until git-completion-helper). So what would you rather have? a) return potentially non-existent completions, or b) don't complete anything? Another idea I had is to have a separate 'git completion-helper' command that could act as a proxy for `git cmd --git-completion-helper` and `git --list-cmds`. The completion would throw a warning if such command is missing, then, the person that installed the completion would have to find a suitable `git completion-helper` command. We could provide an "example" script that contains all these defaults. People could modify this to generate the correct options for different Git versions. Realistically though, most people will just use the defaults for the latest version, but at least the responsibility is not on your side. Cheers. -- Felipe Contreras
