Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

>> * sg/completion-refs-speedup (2017-02-06) 13 commits
>>  - squash! completion: fill COMPREPLY directly when completing refs
>>  - completion: fill COMPREPLY directly when completing refs
>>  - completion: list only matching symbolic and pseudorefs when completing refs
>>  - completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
>>  - completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
>>  - completion: let 'for-each-ref' strip the remote name from remote branches
>>  - completion: let 'for-each-ref' and 'ls-remote' filter matching refs
>>  - completion: don't disambiguate short refs
>>  - completion: don't disambiguate tags and branches
>>  - completion: support excluding full refs
>>  - completion: support completing full refs after '--option=refs/<TAB>'
>>  - completion: wrap __git_refs() for better option parsing
>>  - completion: remove redundant __gitcomp_nl() options from _git_commit()
>>  (this branch uses sg/completion.)
>>
>>  Will hold.
>>  This seems to break 9902 when merged to 'pu'.
>
> All failing tests fail with the same error:
>
>   fatal: unrecognized %(refname:strip=2) argument: strip=2
>
> That's because of this topic:
>
>> * kn/ref-filter-branch-list (2017-01-31) 20 commits
>>   (merged to 'next' on 2017-01-31 at e7592a5461)
>>  + branch: implement '--format' option
>>  + branch: use ref-filter printing APIs
>>  + branch, tag: use porcelain output
>>  + ref-filter: allow porcelain to translate messages in the output
>>  + ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
>>  + ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
>>  + ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
>>  + ref-filter: rename the 'strip' option to 'lstrip'
>
> And in particular this commit, which, well, does what it's subject
> says it's doing, thus breaking backwards compatibility.
>