Re: Improved completion for git commit objects (__git_commit_objects)

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Sat, Mar 7, 2015 at 5:01 AM, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> [ tl;dr: applied patch, attaching further patches for _git and _describe ]
>
> Daniel Hahler wrote on Wed, Mar 04, 2015 at 00:46:42 +0100:
>> Hi,
>>
>> I am trying to improve completion for Git commit objects.
>>
>> __git_commit_objects is defined as follows (in Completion/Unix/Command/_git):
>>
>>     __git_commit_objects () {
>>       _guard '[[:xdigit:]](#c,40)' 'commit object name'
>>     }
>>
>> I think it would be great if it actually (optionally?) could provide
>> completion for commit objects, maybe only on second invocation / as fallback.
>
> Good morning Daniel,
>
> Hope you don't mind, but I went ahead and tweaked your function a bit:
>
> 1. I removed the _guard call which generated a spurious message and
> prevented <TAB> from inserting a unique completion to the command line
> in my configuration.
>
> 2. I used _describe instead of 'compadd -k'.
>
> I've committed the patch with these changes.  Thanks for the patch!
>
> I also made two follow-ups.  The first completes only tags/branches that
> refer to one of the most recent N commits, rather than all tags and
> branches — see attached.  WDYT?
>
> The second follow-up sorts the hashes offered (as completions)
> chronologically, rather than alphabetically, by extending _describe.
> I'd appreciate some review of this one, to make sure I didn't miss
> anything.
>
> With all these patches applied, I get (in the zsh repo):
>
> % git ci --fixup=4<TAB>
>> commit object name
> 4bc554b  -- 34636: replace broken isprint() on Mac OS X
> 42e5f59  -- 34640: clarify documentation for _guard function
> 4edcacb  -- users/19934: document %D{...} for WATCHFMT
> 49776e8  -- 34588: Complete 'usermod -a'

When I tried adding sha1 completion a few years ago, the big
showstopper was that any completion of a commit-ish or any -ish for
that matter, would take several minutes in the linux kernel, since it
has millions of blobs. Is this faster?

-- 
Mikael Magnusson