Re: [PATCH] completion: add 'git history' subcommands
Vincent Mailhol <[email protected]> Wed, 5 Aug 2026 23:20:58 +0200
| Newsgroups | org.kernel.vger.git |
|---|---|
| Message-ID | <[email protected]> |
On 05/08/2026 at 18:15, Junio C Hamano wrote: > Patrick Steinhardt <[email protected]> writes: > >> On Tue, Aug 04, 2026 at 09:56:32PM +0200, Vincent Mailhol wrote: >>> Use the parse-options completion helpers for the "git history" >>> subcommands and their options. Complete positional arguments as >>> revisions, and add coverage for each kind of completion. >> >> Ah, great! I wanted to write shell completion for git-history(1) for a >> while but never really found the time to actually do it. >> >>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash >>> index e875787710..f10813c8d7 100644 >>> --- a/contrib/completion/git-completion.bash >>> +++ b/contrib/completion/git-completion.bash >>> @@ -2137,6 +2137,30 @@ _git_help () >>> fi >>> } >>> >>> +_git_history () >>> +{ >>> + local subcommands subcommand >>> + >>> + __git_resolve_builtins "history" >>> + >>> + subcommands="$___git_resolved_builtins" >>> + subcommand="$(__git_find_subcommand "$subcommands")" >>> + >>> + if [ -z "$subcommand" ]; then >>> + __gitcomp "$subcommands" >>> + return >>> + fi >> >> Okay. We first try to figure out whether there is any subcommand passed >> by the user already. If not, we complete available subcommands. > > This may be a tangent, but anyway. I was looking at this patch (not > that I think I am capable of giving a completion patch a serious > review), comparing with other completions, and the similarity of the > boilerplate part above was so striking. I suspect that these were > organically grown, but at some point when the tree is quiescent, can > we coalesce the completion routines for subcommands that share the > same pattern for better maintainability? I am not sure if this would increase the maintainability. For example, I started looking at Patrick's suggestion ※ to cover the git history split special case. If we add this, we would need to dispatch this in _git_history() by adding something like: if [ "$subcommand" = "split" ]; then __git_complete_history_split return fi but if we coalesce the completion routine for the subcommands, where should this dispatcher go? I see this boilerplate as a skeleton waiting for extensions. Of course, maybe I am missing some points and maybe we can coalesce the code while still allowing for extensions. But currently, I am not able to depict how this should look like. ※ The fact that I started to look at the 'git history split' completion doesn't mean that I am committing myself to implement it. I will do a best effort try in my available time. If I get a decent result, I will share, if not, I would ask you to bear with the current patch! Yours sincerely, Vincent Mailhol