A tuple or subobject works for me.
On Tue, Mar 21, 2017 at 1:45 PM, Jun Wu wrote:
> Excerpts from Ryan McElroy's message of 2017-03-21 20:32:56 +:
>>
>> On 3/21/17 7:34 PM, Jun Wu wrote:
>> > Excerpts from Phillip Cohen's message of 2017-03-21 12:21:33 -0700:
>> >>> Have you
On 3/21/17 7:34 PM, Jun Wu wrote:
Excerpts from Phillip Cohen's message of 2017-03-21 12:21:33 -0700:
Have you actually tried if "commandname" is the command name after resolving
alias?
It is, for command aliases. For example `hg sf` will correctly return `absorb`.
"sf" is unambiguous
On Tue, Mar 21, 2017 at 3:29 PM, Jun Wu wrote:
>> I feel obligated to remind you that we don't offer any stability
>> promises on internals, so if this is a righteous cleanup (using req or
>> similar instead of ui), it's probably worth doing in any case.
>
> I know. In theory we can
Excerpts from Ryan McElroy's message of 2017-03-21 18:56:19 +:
>
> On 3/21/17 6:50 PM, Jun Wu wrote:
> > Excerpts from Augie Fackler's message of 2017-03-21 14:35:43 -0400:
> >> On Mon, Mar 20, 2017 at 12:39:11PM +, Ryan McElroy wrote:
> >>> Overall, I like the functionality this series
(bah, sorry for dropping the list)
On Tue, Mar 21, 2017 at 3:05 PM, Jun Wu wrote:
>>
>> Would it make more sense to have a "request" or "invocation" object that
>> has a ui (and then, eventually, transitively has a config)?
>
> I'm not sure if I follow. The problem is that
+list
> -Original Message-
> From: Augie Fackler [mailto:r...@durin42.com]
> Sent: Tuesday, March 21, 2017 11:55 AM
> To: Jun Wu
> Subject: Re: [PATCH 3 of 3] localrepo: pass args and command running as
> store/write lock metadata
>
> > I think ui.args is useful. We can
On 3/21/17 6:50 PM, Jun Wu wrote:
Excerpts from Augie Fackler's message of 2017-03-21 14:35:43 -0400:
On Mon, Mar 20, 2017 at 12:39:11PM +, Ryan McElroy wrote:
Overall, I like the functionality this series adds, but I'm less convinced
on the specific implementation. Adding more stuff to
On Mon, Mar 20, 2017 at 12:39:11PM +, Ryan McElroy wrote:
> Overall, I like the functionality this series adds, but I'm less convinced
> on the specific implementation. Adding more stuff to the junkyard that is
> the "ui" class doesn't feel awesome, and I'm concerned with how it will
>
Excerpts from Ryan McElroy's message of 2017-03-21 17:18:21 +:
> On 3/21/17 4:40 PM, Jun Wu wrote:
> > Excerpts from Ryan McElroy's message of 2017-03-20 12:39:11 +:
> >> Overall, I like the functionality this series adds, but I'm less
> >> convinced on the specific implementation. Adding
On 3/21/17 4:40 PM, Jun Wu wrote:
Excerpts from Ryan McElroy's message of 2017-03-20 12:39:11 +:
Overall, I like the functionality this series adds, but I'm less
convinced on the specific implementation. Adding more stuff to the
junkyard that is the "ui" class doesn't feel awesome, and I'm
Excerpts from Ryan McElroy's message of 2017-03-20 12:39:11 +:
> Overall, I like the functionality this series adds, but I'm less
> convinced on the specific implementation. Adding more stuff to the
> junkyard that is the "ui" class doesn't feel awesome, and I'm concerned
> with how it will
On Mon, 20 Mar 2017 00:49:07 -0700, Phil Cohen wrote:
> # HG changeset patch
> # User Phil Cohen
> # Date 1489996027 25200
> # Mon Mar 20 00:47:07 2017 -0700
> # Node ID f37121209a2bbcde572e986f2b038bf2da7f954a
> # Parent 1ca023fb02cbe4747e2b5b625866cfa538cbebd3
> localrepo:
> Instead of having this information inside of a lock, what if every
process that started up in a repo tried to create a file in .hg/processes/
(or something) of the form "info.". Then you wouldn't need to pass
this data through to the lock command, wouldn't need to plumb it through
the ui class,
Overall, I like the functionality this series adds, but I'm less
convinced on the specific implementation. Adding more stuff to the
junkyard that is the "ui" class doesn't feel awesome, and I'm concerned
with how it will interact with chg and a future direction of ui
immutability.
I have an
14 matches
Mail list logo