> As an aside from this series, has anyone ever proposed some method of > semi-automatically keeping this up-to-date? For configuration variables, not that I know of. For command line options, there was an attempt to enhance parse-options to dump all command line options and use this in the completion script on-demand to lazy-initialize command-specific variables holding the list of options: http://public-inbox.org/git/1334140165-24958-1-git-send-email-bebarino@xxxxxxxxx/T/#u > Seems we're in a continual > cycle of adding flags/config, forgetting to update this, then updating > it. At least the command-line flags should be easy to parse out in > some test, ditto config variables from config.txt maybe... A couple of thoughts concerning configuration variables: - config.txt includes other files listing configuration variables, too. - There are many config variables with subsections, e.g. 'branch.<name>.description'. That '<name>' is not good for completion, of course. - Some config variables are not listed with their full names, see 'advice.*' (this is easy to fix). - Perhaps there are config variables that are only mentioned in the docs of the relevant command, but not in config.txt (or in the included files). - There are definitely config variables that are not mentioned in the docs at all, e.g. the 'bash.*' variables controlling __git_ps1(). - The completion script is currently self-contained and ready to be used as-is. I think that's quite nice. This wouldn't be the case if we want to include an automatically generated list of config variables extracted from config.txt during the build process.