>
> Perhaps it would unshelve the last change since -n option was discarded.
You are right, i will send V2
2017-02-19 14:53 GMT+01:00 Yuya Nishihara :
> On Sun, 19 Feb 2017 11:07:23 +0100, liscju wrote:
> > # HG changeset patch
> > # User liscju
> > # Date 1487498168 -3600
> > # Sun Feb 1
>
> What is this about? adding a new template directory for evolve?
>
Exactly, i didnt find other way for the extension to add template paths
> As an unrelated notes, we should probaly improve core to make this more
> straight forward.
Easy way to make adding templates for extension easier wou
>
> In such cases can't we handle like, if evolution or the value returned
> is none or empty, don't show the evolution part. Because this empty
> line is bit weird.
Right, i kept this because patch is more a proposal than final solution and
im waiting for opinions about it
2016-09-06 23:21 GMT+
Maybe the way to fix would be just to return
all translated doc with gettext(doc), are there any reason to do additional
parsing?
2016-09-06 14:49 GMT+02:00 Yuya Nishihara :
> On Mon, 5 Sep 2016 22:32:34 +0200, Piotr Listkiewicz wrote:
> > > The change looks good, but this isn't wha
>
> I think having a way to show troubled changesets as such in the log is a
> good idea, but the best we're able to do here is to add a new built-in
> template (cf. `hg log -T phases`). The default log output is very strongly
> a part of our command-line API, and changing it (even additively!) is
>
> The change looks good, but this isn't what issue5228 proposes, which says
> complete docstring should be available for unloaded extensions.
I don't understand it, does it deal with unloaded extension that are not
processed in extensions.loadall(not specified in hgrc)? In this case how do
we k
I have no idea how but i sent this patch two times, so ignore second message
2016-09-05 22:24 GMT+02:00 liscju :
> # HG changeset patch
> # User liscju
> # Date 1472208500 -7200
> # Fri Aug 26 12:48:20 2016 +0200
> # Node ID 63cb64dd80730bc01503b2f28bd159535301f649
> # Parent b1809f5d7630a
>
> As you see, warning messages generally start with lowercase letter, and
> hints
> are surrounded by parens. So I suggest something like this:
> unable to find 'a' for patching
> (use '--prefix .' to apply patch relative to the current directory)
Right, I correct this in V2
2016-09-04 17:
>
> That's a layering violation, and not every backend has a 'repo' (only repo
> backends do). Also I think you're overthinking it; just warn
> unconditionally and let the user sort it out.
You are right, i will send V2
2016-09-01 17:02 GMT+02:00 Kevin Bullock :
> > On Sep 1, 2016, at 09:18, li
