[PATCH 1 of 4 V2] rebase: move destination computation in a revset

[Yuya Nishihara]

On Tue, 22 Sep 2015 14:17:30 -0700, Pierre-Yves David wrote:
> On 09/22/2015 06:02 AM, Yuya Nishihara wrote:
> > On Tue, 22 Sep 2015 01:53:22 -0700, Pierre-Yves David wrote:
> >> # HG changeset patch
> >> # User Pierre-Yves David <pierre-yves.david at fb.com>
> >> # Date 1442512792 25200
> >> #      Thu Sep 17 10:59:52 2015 -0700
> >> # Node ID a2c1596974fc6975f6f6a7e48b8bbb2682e52388
> >> # Parent  4b685712fa454919c121d8d1c967da35b0522dd5
> >> rebase: move destination computation in a revset
> >>
> >> This is the first step toward making the "default destination" logic more clear
> >> and unified. revset is private because I'm happy to delay the bikeshedding until
> >> after the clean up happened.
> >
> >> +def _rebasedefaultdest(repo, subset, x):
> >> +    # ``_rebasedefaultdest()``
> >> +
> >> +    # default destination for rebase.
> >> +    # # XXX: Currently private because I expect the signature to change.
> >> +    # # XXX: - taking rev as arguments,
> >> +    # # XXX: - bailing out in case of ambiguity vs returning all data.
> >> +    # # XXX: - probably merging with the merge destination.
> >> +    # i18n: "_rebasedefaultdest" is a keyword
> >> +    # Destination defaults to the latest revision in the
> >> +    # current branch
> >> +    revset.getargs(x, 0, 0, _("_rebasedefaultdest takes no arguments"))
> >
> > One more nitpicking. "i18n" comment is collected by gettext, so _() message
> > should be placed next to the comment.
> 
> This is a very valid comment. Should I send a V3 or for the queuer want 
> to fix that in flight?

I think he can easily fix it in flight. or should I do?