Sat, Feb 16
Fri, Feb 15
Thu, Feb 14
Hi, it will be good if you specify that the patch is authored by someone else, mention their name and also provide the link to the original PR of this patch.
Wed, Feb 13
Tue, Feb 12
Mon, Feb 11
Sun, Feb 10
nit-pick is resolved. getintrange() will throw a ParseError on setting size to one of min:, :max or :. In ideal case, on calling from expectsize() it shouldn't fail.
Thu, Feb 7
@yuja I've updated the revision with the suggested changes.
Wed, Feb 6
Can you share your failed attempt?
Maybe you can get how revset works by testing expression with
hg debugrevspec -v.
Tue, Feb 5
First, I think the word expect is too general. Perhaps, this should be called
expectsize() or expectlen().
Mon, Feb 4
@pulkit Thanks for the quick review! I've updated the revision with the suggested changes. @durin42 It would be great if you let us know your opinion on one(<set>) as an alias for expect(<set>, 1). I did it as it was present in WeShouldDoThat page.
Sun, Feb 3
Thu, Jan 31
@durin42 Thanks for the quick review.
@mharbison72 Yup. I should not be making changes to the ui as this can be fixed simply within the call itself. My bad. I've updated the revision as per your suggestion, many thanks!
Sorry for bumping this up. I worked on a similar issue on D5490. My initial revision was similar to this one. @spectral Don't you think it'll affect record extension which was written with zero test coverage? Please don't feel obligated. I am just being curious.
Sat, Jan 26
One nit: better to not use .split() since a filename may include whitespace.
Fri, Jan 25
Thanks for queuing this!
Jan 17 2019
Jan 13 2019
_performrevert() would be in the same boat, but it was explicitly flagged on
at f37a69ec3f47. This implies that the diff.ignorews option would be used
in practice to exclude whitespace changes while interactive commit/revert.
So disabling any whitespace options would break someone's workflow.
Jan 12 2019
Jan 11 2019
Sorry for late, but doesn't it break hg record --ignore-all-space, etc.?
Jan 10 2019
@durin42 I've added test for the current revision. Unfortunately, I'm unable to write a test for the wrong behaviour. I'll try writing it again. Any hints from your side?
Could you add a test?
(Bonus points if you add a test that shows the wrong behavior and then fix it in this change.)
Sorry for bumping on this now, can you add tests for this as follow-up?
Jan 9 2019
Jan 7 2019
This is logically incorrect. The problem is that we're doing variable
expansion at too lower layer. vfs(expand(user_specified_path)) makes
some sense, but vfs(expand(getcwd())) is clearly wrong. And the vfs class
can't know where the base comes from.
Jan 5 2019
I am not sure whether this change is correct or not, but please add more description to your commit message explaining what this patch is doing, what the issue is about and how it fixes that.
Jan 4 2019
Jan 3 2019
Thanks for queuing!
Thanks for queuing Yuya!
Jan 2 2019
@yuja Can this be closed?
@yuja Requested changes have been made in the current revision.
Dec 30 2018
IIUC, the problem is that the width parameter is incorrect because of
Dec 28 2018
Dec 27 2018
I tried to queue this, but the patch doesn't include any metadata (e.g. author
and date.) Please check your configuration.
Dec 26 2018
Looks mostly good.
Can you update the commit message to conform to our style?
Dec 25 2018
@yuja Thank you so much for the information. I've updated the revision. Please review when you're free.
Dec 24 2018
+ rev = ctx.rev()
+ if opts.get('rev') and rev not in revs:
ctx points to the tipmost branch head. so rev not in revs doesn't mean any
of the revs do not belong to the branch.
Thanks for the info @yuja. I'm thinking to move --rev/-r to branches command and replacing --show/-s that I've made to --rev/-r in the branch command itself.
I'm not sure if I get it, but my idea is to add hg branches -r/--rev
that selects branches to be listed by revisions. So, hg branch -srREV in
your original patch will be equivalent to hg branches -qrREV (-q to
suppress detailed output.)
Dec 23 2018
Thanks for the info @yuja. I'm thinking to move --rev/-r to branches command and replacing --show/-s that I've made to --rev/-r in the branch command itself. How's that sound to you guys, @pulkit @yuja ?