D4267: zsh_completion: update all options
spectral (Kyle Lippincott)
phabricator at mercurial-scm.org
Mon Aug 13 14:59:07 EDT 2018
spectral accepted this revision.
spectral added inline comments.
INLINE COMMENTS
> zsh_completion:373
> # Common options
> _hg_global_opts=(
> + '(--repository -R)'{-R+,--repository=}'[repository root directory or name of overlay bundle file]:repository:_files -/'
I wonder how hard it would be to add tests to make sure these don't diverge from the actual output in the future? (no action required in this change, just curious if you have any ideas).
At my job our code review system has a "if this is modified, then you probably want to modify this other place" mechanism, I wonder if something like that, generically as part of one of the existing tests (or on its own) would be easier and make more sense than attempting to match the output, just rely on people doing the right thing when the tests prompt them to (with a way of ignoring it, perhaps via something in the commit description). Example:
1. IfChange @command('^add', walkopts + subrepoopts + dryrunopts, _('[OPTION]... [FILE]...'), inferrrepo=True)
2. ThenChange(contrib/zsh_completion, contrib/bash_completion) def add(ui, repo, *pats, **opts): ...
Though, since we'd be doing this for every @command, I'm back to thinking it'd probably be better to hard-code it for the completion stuff - something that says "Oh, you've modified the contents of an @command, make sure you update these other locations as well..."
> zsh_completion:644
> + '*'{-r+,--rev=}'[revisions to graft]:revision:_hg_labels' \
> + '(--continue -c --abort -a)'{-c,--continue}'[resume interrupted graft]' \
> + '(--continue -c --abort -a)'{-a,--abort}'[abort interrupted graft]' \
I assume the first section here makes continue and abort mutually exclusive? I believe that revision arguments are also forbidden if either --continue or --abort are specified; I don't know if there's a way of representing that.
> zsh_completion:828
> '(--mark -m --list -l --unmark -u)'{-m,--mark}'[mark files as resolved]:*:unresolved files:_hg_unresolved' \
> - '(--unmark -u --list -l --mark -m)'{-u,--unmark}'[unmark files as resolved]:*:resolved files:_hg_resolved' \
> + '(--unmark -u --list -l --mark -m)'{-u,--unmark}'[mark files as unresolved]:*:resolved files:_hg_resolved' \
> '*:file:_hg_unresolved' && ret=0
Does the order of the first section matter? Should the three of them be identical?
> zsh_completion:1198
> _arguments -s -S : $_hg_global_opts $_hg_commit_opts $_hg_mergetool_opts \
> '*'{-r+,--rev=}'[rebase these revisions]:revision:_hg_revrange' \
> + '(--source -s --base -b)'{-s+,--source=}'[rebase the specified changeset and descendants]:revision:_hg_labels' \
Does this indicate that `hg rebase <hash> -d <dest>` should work (without a `-r`, `-s`, or `-b`?) I don't think that's correct..
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D4267
To: av6, #hg-reviewers, spectral
Cc: spectral, mercurial-devel
More information about the Mercurial-devel
mailing list