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

On Mon, Feb 6, 2017 at 4:24 PM, SZEDER Gábor [off-list ref] wrote:

quoted

* 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:

quoted

* 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.

What about making strip a deprecated variant of lstrip?

Thanks,
Jake