Re: [PATCH] completion: add 'git history' subcommands

[Vincent Mailhol <mailhol@kernel.org>]

On 05/08/2026 at 18:15, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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