Re: [PATCH v3 rebased] pager: migrate heavily-used extension into core

[Sean Farley]

Augie Fackler  writes:

>> On Feb 6, 2017, at 14:47, Bryan O'Sullivan  wrote:
>> 
>> # HG changeset patch
>> # User Bryan O'Sullivan 
>> # Date 1486160890 28800
>> #  Fri Feb 03 14:28:10 2017 -0800
>> # Node ID ae22925dafd4a270cb80a7bb54c9d70bce49a633
>> # Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
>> pager: migrate heavily-used extension into core
>
> Here's my counterproposal, not quite done enough to mail (mostly on account 
> of it being late in my timezone):
>
> https://hg.durin42.com/hg-wip/log?rev=%40%3A%3A7c0170f0420f%20-%20%40=50
>
> It's 32 patches (but most of them are one line, turning on paging of a 
> command), and probably breaks some hairy edges of the pager extension in the 
> name of moving the behavior to core behind a more usable API. I only touched 
> commands in core or that were mentioned in pager.attend, so there's another 
> round of changes to make in hgext to get things fully on the pager bandwagon. 
> That said: it should work! Tests pass modulo small things you'd sort of 
> expect: lots of output churn from the new global variable, and one `help -k` 
> test fails because I marked the pager extension as deprecated.
>
> I'll try and coordinate with someone on IRC tomorrow to go over this with me 
> and get it mailed, since it sounded like everyone on the other thread was 
> largely enthusiastic about this direction.

Wow, impressive!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] chg: verify XDG_RUNTIME_DIR

[Augie Fackler]

> On Feb 6, 2017, at 20:03, Jun Wu  wrote:
> 
> # HG changeset patch
> # User Jun Wu 
> # Date 1486429266 28800
> #  Mon Feb 06 17:01:06 2017 -0800
> # Node ID 8081cb8c346f1ccfa8c98e94d7e25cdfccafeb06
> # Parent  b6c051cd1231910b0981edb01b173cd53a3338d0
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> 8081cb8c346f
> chg: verify XDG_RUNTIME_DIR

queued, thanks

> 
> According to the specification [1], $XDG_RUNTIME_DIR should be ignored
> unless:
> 
>  The directory MUST be owned by the user, and he MUST be the only one
>  having read and write access to it. Its Unix access mode MUST be 0700.
> 
> This patch adds a check and ignores it if it does not meet part of the
> criteria.
> 
> [1]: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> diff --git a/contrib/chg/chg.c b/contrib/chg/chg.c
> --- a/contrib/chg/chg.c
> +++ b/contrib/chg/chg.c
> @@ -129,4 +129,22 @@ static void preparesockdir(const char *s
> }
> 
> +/*
> + * Check if a socket directory exists and is only owned by the current user.
> + * Return 1 if so, 0 if not. This is used to check if XDG_RUNTIME_DIR can be
> + * used or not. According to the specification [1], XDG_RUNTIME_DIR should be
> + * ignored if the directory is not owned by the user with mode 0700.
> + * [1]: 
> https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> + */
> +static int checkruntimedir(const char *sockdir)
> +{
> + struct stat st;
> + int r = lstat(sockdir, );
> + if (r < 0) /* ex. does not exist */
> + return 0;
> + if (!S_ISDIR(st.st_mode)) /* ex. is a file, not a directory */
> + return 0;
> + return st.st_uid == geteuid() && (st.st_mode & 0777) == 0700;
> +}
> +
> static void getdefaultsockdir(char sockdir[], size_t size)
> {
> @@ -136,5 +154,5 @@ static void getdefaultsockdir(char sockd
>   const char *runtimedir = getenv("XDG_RUNTIME_DIR");
>   int r;
> - if (runtimedir) {
> + if (runtimedir && checkruntimedir(runtimedir)) {
>   r = snprintf(sockdir, size, "%s/chg", runtimedir);
>   } else {
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] check-code: permit functools.reduce

[Augie Fackler]

> On Feb 6, 2017, at 17:22, Yedidya Feldblum  wrote:
> 
> # HG changeset patch
> # User Yedidya Feldblum 
> # Date 1485038593 28800
> #  Sat Jan 21 14:43:13 2017 -0800
> # Node ID 47d8e895ccb734f0219dd046795b042da002b06b
> # Parent  036c37bd3ec189480647ff568cee9e0b43a5bc81
> check-code: permit functools.reduce

Sure, queued.


> diff --git a/contrib/check-code.py b/contrib/check-code.py
> --- a/contrib/check-code.py
> +++ b/contrib/check-code.py
> @@ -237,7 +237,7 @@
> (r'lambda\s*\(.*,.*\)',
>  "tuple parameter unpacking not available in Python 3+"),
> (r'(? -(r'\breduce\s*\(.*', "reduce is not available in Python 3+"),
> +(r'(? (r'\bdict\(.*=', 'dict() is different in Py2 and 3 and is slower than {}',
>  'dict-from-generator'),
> (r'\.has_key\b', "dict.has_key is not available in Python 3+"),
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Augie Fackler]

> On Feb 6, 2017, at 19:26, Jun Wu  wrote:
> 
>> As a sketch of where this is headed, API-wise:
>> 
>> class ui:
>> def pager(self, command, category):
> 
> Just to confirm if I understand correctly, command and category are only
> used to find out the actual pager command from the config? That looks good.
> Maybe swap category and command and make command (or both) optional, to
> discourage using commands in configs.

I couldn't quite wrap my head around categories in the end. The categories I 
could sort of see are:

cat:
  cat, annotate, grep
status:
  status, summary, resolve
log:
  log, tags, incoming, outgoing
diff:
  export, {log, incoming, outgoing with --patch}, qdiff
???:
  files, manifest, locate, help

For now, the series discards the notion of a category in the 10th patch or so, 
but we can easily re-add it or make it the preferred option if we can figure 
out what the ontology is here.

If you want to see the work in progress stack, it's here: 
https://hg.durin42.com/hg-wip/log?rev=%40%3A%3A7c0170f0420f%20-%20%40=50
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v3 rebased] pager: migrate heavily-used extension into core

[Augie Fackler]

> On Feb 6, 2017, at 14:47, Bryan O'Sullivan  wrote:
> 
> # HG changeset patch
> # User Bryan O'Sullivan 
> # Date 1486160890 28800
> #  Fri Feb 03 14:28:10 2017 -0800
> # Node ID ae22925dafd4a270cb80a7bb54c9d70bce49a633
> # Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
> pager: migrate heavily-used extension into core

Here's my counterproposal, not quite done enough to mail (mostly on account of 
it being late in my timezone):

https://hg.durin42.com/hg-wip/log?rev=%40%3A%3A7c0170f0420f%20-%20%40=50

It's 32 patches (but most of them are one line, turning on paging of a 
command), and probably breaks some hairy edges of the pager extension in the 
name of moving the behavior to core behind a more usable API. I only touched 
commands in core or that were mentioned in pager.attend, so there's another 
round of changes to make in hgext to get things fully on the pager bandwagon. 
That said: it should work! Tests pass modulo small things you'd sort of expect: 
lots of output churn from the new global variable, and one `help -k` test fails 
because I marked the pager extension as deprecated.

I'll try and coordinate with someone on IRC tomorrow to go over this with me 
and get it mailed, since it sounded like everyone on the other thread was 
largely enthusiastic about this direction.

> No default behaviours were harmed during the making of this change.
> 
> Notes:
> 
> * This patch will break out-of-tree extensions that rely on the
>  location of the old pager module's attend variable.  It is now a
>  static variable named pagercommands on the ui class.
> 
> * It used to be possible to disable the pager via config by disabling
>  the loading of the extension.  With the extension gone, that
>  method no longer works.  Instead, set pager.attend to a command
>  that does not exist, e.g. "--config pager.attend=nothing".
> 
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -107,6 +107,8 @@ globalopts = [
> ('', 'version', None, _('output version information and exit')),
> ('h', 'help', None, _('display help and exit')),
> ('', 'hidden', False, _('consider hidden changesets')),
> +('', 'pager', 'auto',
> + _("when to paginate (boolean, always, auto, or never)"), _('TYPE')),
> ]
> 
> dryrunopts = [('n', 'dry-run', None,
> diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
> --- a/mercurial/dispatch.py
> +++ b/mercurial/dispatch.py
> @@ -816,6 +816,37 @@ def _dispatch(req):
> def _runcommand(ui, options, cmd, cmdfunc):
> """Run a command function, possibly with profiling enabled."""
> try:
> +p = ui.config("pager", "pager", encoding.environ.get("PAGER"))
> +usepager = ui.pageractive
> +always = util.parsebool(options['pager'])
> +auto = options['pager'] == 'auto'
> +
> +if not p or '--debugger' in sys.argv or not ui.formatted():
> +pass
> +elif always:
> +usepager = True
> +elif not auto:
> +usepager = False
> +else:
> +attend = ui.configlist('pager', 'attend', ui.pagercommands)
> +ignore = ui.configlist('pager', 'ignore')
> +cmds, _ = cmdutil.findcmd(cmd, commands.table)
> +
> +for cmd in cmds:
> +var = 'attend-%s' % cmd
> +if ui.config('pager', var):
> +usepager = ui.configbool('pager', var)
> +break
> +if cmd in attend or (cmd not in ignore and not attend):
> +usepager = True
> +break
> +
> +ui.pageractive = usepager
> +
> +if usepager:
> +ui.setconfig('ui', 'formatted', ui.formatted(), 'pager')
> +ui.setconfig('ui', 'interactive', False, 'pager')
> +ui._runpager(p)
> return cmdfunc()
> except error.SignatureError:
> raise error.CommandError(cmd, _('invalid arguments'))
> diff --git a/mercurial/extensions.py b/mercurial/extensions.py
> --- a/mercurial/extensions.py
> +++ b/mercurial/extensions.py
> @@ -27,7 +27,7 @@ from . import (
> _aftercallbacks = {}
> _order = []
> _builtin = set(['hbisect', 'bookmarks', 'parentrevspec', 'progress', 
> 'interhg',
> -'inotify', 'hgcia'])
> +'inotify', 'hgcia', 'pager'])
> 
> def extensions(ui=None):
> if ui:
> diff --git a/mercurial/help.py b/mercurial/help.py
> --- a/mercurial/help.py
> +++ b/mercurial/help.py
> @@ -230,6 +230,7 @@ helptable = sorted([
>  loaddoc('scripting')),
> (['internals'], _("Technical implementation topics"),
>  internalshelp),
> +(["pager"], _("Using an External Pager"), loaddoc('pager')),
> ])
> 
> # Maps topics with sub-topics to a list of their sub-topics.
> diff --git a/hgext/pager.py b/mercurial/help/pager.txt
> rename from hgext/pager.py
> rename to mercurial/help/pager.txt
> --- a/hgext/pager.py

[PATCH] chg: verify XDG_RUNTIME_DIR

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1486429266 28800
#  Mon Feb 06 17:01:06 2017 -0800
# Node ID 8081cb8c346f1ccfa8c98e94d7e25cdfccafeb06
# Parent  b6c051cd1231910b0981edb01b173cd53a3338d0
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 8081cb8c346f
chg: verify XDG_RUNTIME_DIR

According to the specification [1], $XDG_RUNTIME_DIR should be ignored
unless:

  The directory MUST be owned by the user, and he MUST be the only one
  having read and write access to it. Its Unix access mode MUST be 0700.

This patch adds a check and ignores it if it does not meet part of the
criteria.

[1]: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

diff --git a/contrib/chg/chg.c b/contrib/chg/chg.c
--- a/contrib/chg/chg.c
+++ b/contrib/chg/chg.c
@@ -129,4 +129,22 @@ static void preparesockdir(const char *s
 }
 
+/*
+ * Check if a socket directory exists and is only owned by the current user.
+ * Return 1 if so, 0 if not. This is used to check if XDG_RUNTIME_DIR can be
+ * used or not. According to the specification [1], XDG_RUNTIME_DIR should be
+ * ignored if the directory is not owned by the user with mode 0700.
+ * [1]: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
+ */
+static int checkruntimedir(const char *sockdir)
+{
+   struct stat st;
+   int r = lstat(sockdir, );
+   if (r < 0) /* ex. does not exist */
+   return 0;
+   if (!S_ISDIR(st.st_mode)) /* ex. is a file, not a directory */
+   return 0;
+   return st.st_uid == geteuid() && (st.st_mode & 0777) == 0700;
+}
+
 static void getdefaultsockdir(char sockdir[], size_t size)
 {
@@ -136,5 +154,5 @@ static void getdefaultsockdir(char sockd
const char *runtimedir = getenv("XDG_RUNTIME_DIR");
int r;
-   if (runtimedir) {
+   if (runtimedir && checkruntimedir(runtimedir)) {
r = snprintf(sockdir, size, "%s/chg", runtimedir);
} else {
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-02-06 17:52:30 -0500:
> (sending again because this seems to have gotten stuck somewhere...)
> (+yuya explicitly for chg thoughts, +smf so someone else can forward to the 
> list if it's stuck again)

chg would be fine so long as ui.pager() calls ui._runpager().

> [snip]
> How does that sound, overall? I'll tackle the refactoring today or
> Wednesday to mail an RFC patch if that doesn't sound too much like the
> perfect being the enemy of the good.
> 
> (This design, btw, was inspired by the way git handles paging, where
> it's largely up to the command to decide if it wants to invoke the
> pager.)

The API is not new to me, I'm +1 on it, and did the chg ui._runpager
refactoring to make the change easier.

The only concern I have is the amount of work actually needed to finish the
change. It probably has to be a separate series.
 
> As a sketch of where this is headed, API-wise:
> 
> class ui:
>  def pager(self, command, category):

Just to confirm if I understand correctly, command and category are only
used to find out the actual pager command from the config? That looks good.
Maybe swap category and command and make command (or both) optional, to
discourage using commands in configs.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Sean Farley]

Augie Fackler  writes:

>> On Feb 6, 2017, at 18:32, Sean Farley  wrote:
>> 
>> Augie Fackler  writes:
>> 
 On Feb 6, 2017, at 18:04, Sean Farley  wrote:
 
 Augie Fackler  writes:
 
> (sending again because this seems to have gotten stuck somewhere...)
> (+yuya explicitly for chg thoughts, +smf so someone else can forward to 
> the list if it's stuck again)
> 
> On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
>>> [...]
>>> 
> (This design, btw, was inspired by the way git handles paging, where
> it's largely up to the command to decide if it wants to invoke the
> pager.)
 
 If I'm understanding you correctly, this will get rid of the
 pager.attend variable? If that's true, then I fully support that.
>>> 
>>> Mostly. pager.attend will probably live on as a config knob for users to 
>>> force paging of commands that don't request it. I can't see it working 
>>> without that? Though it'd be the alternative form, that looks like
>> 
>> You mean for third-party commands?
>
> Yep.
>
>> My conclusion from your previous
>> email was that all the internal commands would eventually be patched to
>> use ui.pager, right?
>
> Most, not all. commit doesn't really want a pager, and summary probably 
> doesn't want it as a default? We'll have to do some fiddling around the 
> margins, but yes, I'm thinking I'll include in my series moving 
> log/export/diff and friends to the new API.

Ok, I see. Sounds good to me.

>>> [pager]
>>> attend-foo = yes
>> 
>> Is there anything preventing this form?
>
> I believe this already works...

Ha, ok, shows how much I dig into pager.attend code.

> As a sketch of where this is headed, API-wise:
> 
> class ui:
> def pager(self, command, category):
>  ""Starts the pager, if desired by the user.
> 
>  `command` specifies the current command the user is running,
>  something like `log` or `shelve`. It should be the whole original
>  command name, not the partial name or alias name.
> 
>  `category` specifies a broad category this pager invocation fits
>  into. Examples include `diff`, `log`, `status`, `help`. This
>  allows users to disable paging of entire types of commands easily.
>  """
>  # pager starts, self.pageractive=true, etc
> 
> @command
> def shelve(ui, ...):
> if action == 'list':
>  ui.pager('shelve', 'diff' if --patch else 'log')
> ...
> 
> @command
> def summary(ui, ...):
> ui.pager('summary', 'status')
> ...
 
 Would this get rid of the need to set pager.pager=less? I think last
 time the pager was brought up (I believe the Munich sprint), there was a
 consensus on not relying on the existence of less / more / windows
 weirdness.
>>> 
>>> I don't know about Windows, but I think we should follow git's lead and 
>>> default to using *a* pager. On debian, that means sensible-pager, on most 
>>> other unices that means less, on some unfortunate platforms it means more. 
>>> In-tree, we should probably default to more, with a recommendation that 
>>> packagers specify a more reasonable default in the system-wide hgrc.
>>> 
>>> (I've had a PAGER environment variable for longer than I've had my dotfiles 
>>> source control, but I have no idea how common this is. For some highly 
>>> unscientific data, I've posted a poll on twitter: 
>>> https://twitter.com/durin42/status/828742645145075712 - maybe we'll learn 
>>> something.)
>> 
>> Hmmm, I seem to recall talk about vendoring a python pager? Didn't
>> Anatoly write one?
>
> I honestly have no idea - someone with a windows clue will probably need to 
> fill in the sensible windows defaults.
>
> (I'm -0 on bundling a pager, but maybe we'll have to do that on windows...)

No worries. It's always something we can add / decide on later. I look
forward to this API and getting pager into core :-)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] check-code: permit functools.reduce

[Sean Farley]

Yedidya Feldblum  writes:

> # HG changeset patch
> # User Yedidya Feldblum 
> # Date 1485038593 28800
> #  Sat Jan 21 14:43:13 2017 -0800
> # Node ID 47d8e895ccb734f0219dd046795b042da002b06b
> # Parent  036c37bd3ec189480647ff568cee9e0b43a5bc81
> check-code: permit functools.reduce

I guess? Maybe Augie should look at this, though.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Augie Fackler]

> On Feb 6, 2017, at 18:32, Sean Farley  wrote:
> 
> Augie Fackler  writes:
> 
>>> On Feb 6, 2017, at 18:04, Sean Farley  wrote:
>>> 
>>> Augie Fackler  writes:
>>> 
 (sending again because this seems to have gotten stuck somewhere...)
 (+yuya explicitly for chg thoughts, +smf so someone else can forward to 
 the list if it's stuck again)
 
 On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
>> [...]
>> 
 (This design, btw, was inspired by the way git handles paging, where
 it's largely up to the command to decide if it wants to invoke the
 pager.)
>>> 
>>> If I'm understanding you correctly, this will get rid of the
>>> pager.attend variable? If that's true, then I fully support that.
>> 
>> Mostly. pager.attend will probably live on as a config knob for users to 
>> force paging of commands that don't request it. I can't see it working 
>> without that? Though it'd be the alternative form, that looks like
> 
> You mean for third-party commands?

Yep.

> My conclusion from your previous
> email was that all the internal commands would eventually be patched to
> use ui.pager, right?

Most, not all. commit doesn't really want a pager, and summary probably doesn't 
want it as a default? We'll have to do some fiddling around the margins, but 
yes, I'm thinking I'll include in my series moving log/export/diff and friends 
to the new API.

> 
>> [pager]
>> attend-foo = yes
> 
> Is there anything preventing this form?

I believe this already works...

> 
 As a sketch of where this is headed, API-wise:
 
 class ui:
 def pager(self, command, category):
  ""Starts the pager, if desired by the user.
 
  `command` specifies the current command the user is running,
  something like `log` or `shelve`. It should be the whole original
  command name, not the partial name or alias name.
 
  `category` specifies a broad category this pager invocation fits
  into. Examples include `diff`, `log`, `status`, `help`. This
  allows users to disable paging of entire types of commands easily.
  """
  # pager starts, self.pageractive=true, etc
 
 @command
 def shelve(ui, ...):
 if action == 'list':
  ui.pager('shelve', 'diff' if --patch else 'log')
 ...
 
 @command
 def summary(ui, ...):
 ui.pager('summary', 'status')
 ...
>>> 
>>> Would this get rid of the need to set pager.pager=less? I think last
>>> time the pager was brought up (I believe the Munich sprint), there was a
>>> consensus on not relying on the existence of less / more / windows
>>> weirdness.
>> 
>> I don't know about Windows, but I think we should follow git's lead and 
>> default to using *a* pager. On debian, that means sensible-pager, on most 
>> other unices that means less, on some unfortunate platforms it means more. 
>> In-tree, we should probably default to more, with a recommendation that 
>> packagers specify a more reasonable default in the system-wide hgrc.
>> 
>> (I've had a PAGER environment variable for longer than I've had my dotfiles 
>> source control, but I have no idea how common this is. For some highly 
>> unscientific data, I've posted a poll on twitter: 
>> https://twitter.com/durin42/status/828742645145075712 - maybe we'll learn 
>> something.)
> 
> Hmmm, I seem to recall talk about vendoring a python pager? Didn't
> Anatoly write one?

I honestly have no idea - someone with a windows clue will probably need to 
fill in the sensible windows defaults.

(I'm -0 on bundling a pager, but maybe we'll have to do that on windows...)

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] check-code: permit functools.reduce

[Yedidya Feldblum]

# HG changeset patch
# User Yedidya Feldblum 
# Date 1485038593 28800
#  Sat Jan 21 14:43:13 2017 -0800
# Node ID 47d8e895ccb734f0219dd046795b042da002b06b
# Parent  036c37bd3ec189480647ff568cee9e0b43a5bc81
check-code: permit functools.reduce

diff --git a/contrib/check-code.py b/contrib/check-code.py
--- a/contrib/check-code.py
+++ b/contrib/check-code.py
@@ -237,7 +237,7 @@
 (r'lambda\s*\(.*,.*\)',
  "tuple parameter unpacking not available in Python 3+"),
 (r'(?https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Sean Farley]

Augie Fackler  writes:

>> On Feb 6, 2017, at 18:04, Sean Farley  wrote:
>> 
>> Augie Fackler  writes:
>> 
>>> (sending again because this seems to have gotten stuck somewhere...)
>>> (+yuya explicitly for chg thoughts, +smf so someone else can forward to the 
>>> list if it's stuck again)
>>> 
>>> On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
> [...]
>
>>> (This design, btw, was inspired by the way git handles paging, where
>>> it's largely up to the command to decide if it wants to invoke the
>>> pager.)
>> 
>> If I'm understanding you correctly, this will get rid of the
>> pager.attend variable? If that's true, then I fully support that.
>
> Mostly. pager.attend will probably live on as a config knob for users to 
> force paging of commands that don't request it. I can't see it working 
> without that? Though it'd be the alternative form, that looks like

You mean for third-party commands? My conclusion from your previous
email was that all the internal commands would eventually be patched to
use ui.pager, right?

> [pager]
> attend-foo = yes

Is there anything preventing this form?

>>> As a sketch of where this is headed, API-wise:
>>> 
>>> class ui:
>>> def pager(self, command, category):
>>>   ""Starts the pager, if desired by the user.
>>> 
>>>   `command` specifies the current command the user is running,
>>>   something like `log` or `shelve`. It should be the whole original
>>>   command name, not the partial name or alias name.
>>> 
>>>   `category` specifies a broad category this pager invocation fits
>>>   into. Examples include `diff`, `log`, `status`, `help`. This
>>>   allows users to disable paging of entire types of commands easily.
>>>   """
>>>   # pager starts, self.pageractive=true, etc
>>> 
>>> @command
>>> def shelve(ui, ...):
>>> if action == 'list':
>>>   ui.pager('shelve', 'diff' if --patch else 'log')
>>> ...
>>> 
>>> @command
>>> def summary(ui, ...):
>>> ui.pager('summary', 'status')
>>> ...
>> 
>> Would this get rid of the need to set pager.pager=less? I think last
>> time the pager was brought up (I believe the Munich sprint), there was a
>> consensus on not relying on the existence of less / more / windows
>> weirdness.
>
> I don't know about Windows, but I think we should follow git's lead and 
> default to using *a* pager. On debian, that means sensible-pager, on most 
> other unices that means less, on some unfortunate platforms it means more. 
> In-tree, we should probably default to more, with a recommendation that 
> packagers specify a more reasonable default in the system-wide hgrc.
>
> (I've had a PAGER environment variable for longer than I've had my dotfiles 
> source control, but I have no idea how common this is. For some highly 
> unscientific data, I've posted a poll on twitter: 
> https://twitter.com/durin42/status/828742645145075712 - maybe we'll learn 
> something.)

Hmmm, I seem to recall talk about vendoring a python pager? Didn't
Anatoly write one?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 08 of 10 shelve-ext v3] shelve: add obs-based unshelve functionality

[Sean Farley]

Kostia Balytskyi  writes:

> On 06/02/2017 19:41, Sean Farley wrote:
>
>> Kostia Balytskyi  writes:
>>
>>> On 03/02/2017 23:17, Sean Farley wrote:
>>>
 Kostia Balytskyi  writes:

> # HG changeset patch
> # User Kostia Balytskyi 
> # Date 1484835394 28800
> #  Thu Jan 19 06:16:34 2017 -0800
> # Node ID 94a237a046059ef246aacb2c3ad809c9f0bdbe70
> # Parent  abdf9565fdce15604ea4abf013cb7c98a11f70ca
> shelve: add obs-based unshelve functionality
>
> Obsolescense-based unshelve works as follows:
> 1. Instead of stripping temporary nodes, markers are created to
> obsolete them.
> 2. Restoring commit is just finding it in an unfiltered repo.
> 3. '--keep' is only passed to rebase on traditional unshelves
> (and thus traditional rebases), becuase we want markers to be
> created fro obsolete-based rebases.
> 4. 'hg unshelve' uses unfiltered repo to perform rebases
> because we want rebase to be able to create markers between original
> and new commits. 'rebaseskipobsolete' is disabled to make rebase not
> skip the commit altogether.
 Before this gets into core, can we not implement stripping obs markers?
 This seems like a good use-case for such functionality.
>>> I am not sure I understand why stripping obs-markers is a pre-requisite
>>> here. Can you explain?
>> Perhaps I'm the only one worried about adding all these markers. To me,
>> it would make more sense to delete these markers since we're never going
>> to push these shelved changesets.
> Deleting markers would mean changesets are no longer hidden, no? And if 
> you want to strip changesets as well, then I don't see the point in 
> having markers at all.

Ah, yep, I forgot my version was performing a strip. We'd need the
markers to not be stripped in this case.

>> Also, this sounds like we're overloading the concept of markers. In the
>> past, I have wanted a concept of "markers that hide changesets" but to
>> group them into different namespaces. For example, remote branches not
>> checked out locally could be hidden into one such group, shelved changes
>> into another group, etc.
>>
>> Though, I do realize I might be derailing this topic by trying to
>> generalize this.
> I don't think I understand your opinion about markers, but it probably 
> applies more broadly than
> just obs-shelve.

Discovery and exchange of markers is absurdly slow. *Absurdly*. I'm not
saying we should block features due to technical limitations (and a
promise that discovery will be "fixed" ... one day ... maybe next year).
I'm just saying we should think really hard about using them like this.

> This direction of doing shelve was discussed on the 
> last sprint and people who participated
> did not seem much against it :)

Keep in mind not everyone gets to participate in the sprint discussions.
I think sprint discussions are fine for agreeing that something should
be worked on but in no way should override a patch review.

I'll go through this series more in-depth now unless someone beats me to
it.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 08 of 10 shelve-ext v3] shelve: add obs-based unshelve functionality

[Kostia Balytskyi]

On 06/02/2017 19:41, Sean Farley wrote:

> Kostia Balytskyi  writes:
>
>> On 03/02/2017 23:17, Sean Farley wrote:
>>
>>> Kostia Balytskyi  writes:
>>>
 # HG changeset patch
 # User Kostia Balytskyi 
 # Date 1484835394 28800
 #  Thu Jan 19 06:16:34 2017 -0800
 # Node ID 94a237a046059ef246aacb2c3ad809c9f0bdbe70
 # Parent  abdf9565fdce15604ea4abf013cb7c98a11f70ca
 shelve: add obs-based unshelve functionality

 Obsolescense-based unshelve works as follows:
 1. Instead of stripping temporary nodes, markers are created to
 obsolete them.
 2. Restoring commit is just finding it in an unfiltered repo.
 3. '--keep' is only passed to rebase on traditional unshelves
 (and thus traditional rebases), becuase we want markers to be
 created fro obsolete-based rebases.
 4. 'hg unshelve' uses unfiltered repo to perform rebases
 because we want rebase to be able to create markers between original
 and new commits. 'rebaseskipobsolete' is disabled to make rebase not
 skip the commit altogether.
>>> Before this gets into core, can we not implement stripping obs markers?
>>> This seems like a good use-case for such functionality.
>> I am not sure I understand why stripping obs-markers is a pre-requisite
>> here. Can you explain?
> Perhaps I'm the only one worried about adding all these markers. To me,
> it would make more sense to delete these markers since we're never going
> to push these shelved changesets.
Deleting markers would mean changesets are no longer hidden, no? And if 
you want to strip changesets as well, then I don't see the point in 
having markers at all.
> Also, this sounds like we're overloading the concept of markers. In the
> past, I have wanted a concept of "markers that hide changesets" but to
> group them into different namespaces. For example, remote branches not
> checked out locally could be hidden into one such group, shelved changes
> into another group, etc.
>
> Though, I do realize I might be derailing this topic by trying to
> generalize this.
I don't think I understand your opinion about markers, but it probably 
applies more broadly than
just obs-shelve. This direction of doing shelve was discussed on the 
last sprint and people who participated
did not seem much against it :)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Augie Fackler]

> On Feb 6, 2017, at 18:04, Sean Farley  wrote:
> 
> Augie Fackler  writes:
> 
>> (sending again because this seems to have gotten stuck somewhere...)
>> (+yuya explicitly for chg thoughts, +smf so someone else can forward to the 
>> list if it's stuck again)
>> 
>> On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
[...]

>> (This design, btw, was inspired by the way git handles paging, where
>> it's largely up to the command to decide if it wants to invoke the
>> pager.)
> 
> If I'm understanding you correctly, this will get rid of the
> pager.attend variable? If that's true, then I fully support that.

Mostly. pager.attend will probably live on as a config knob for users to force 
paging of commands that don't request it. I can't see it working without that? 
Though it'd be the alternative form, that looks like

[pager]
attend-foo = yes

> 
>> As a sketch of where this is headed, API-wise:
>> 
>> class ui:
>> def pager(self, command, category):
>>   ""Starts the pager, if desired by the user.
>> 
>>   `command` specifies the current command the user is running,
>>   something like `log` or `shelve`. It should be the whole original
>>   command name, not the partial name or alias name.
>> 
>>   `category` specifies a broad category this pager invocation fits
>>   into. Examples include `diff`, `log`, `status`, `help`. This
>>   allows users to disable paging of entire types of commands easily.
>>   """
>>   # pager starts, self.pageractive=true, etc
>> 
>> @command
>> def shelve(ui, ...):
>> if action == 'list':
>>   ui.pager('shelve', 'diff' if --patch else 'log')
>> ...
>> 
>> @command
>> def summary(ui, ...):
>> ui.pager('summary', 'status')
>> ...
> 
> Would this get rid of the need to set pager.pager=less? I think last
> time the pager was brought up (I believe the Munich sprint), there was a
> consensus on not relying on the existence of less / more / windows
> weirdness.

I don't know about Windows, but I think we should follow git's lead and default 
to using *a* pager. On debian, that means sensible-pager, on most other unices 
that means less, on some unfortunate platforms it means more. In-tree, we 
should probably default to more, with a recommendation that packagers specify a 
more reasonable default in the system-wide hgrc.

(I've had a PAGER environment variable for longer than I've had my dotfiles 
source control, but I have no idea how common this is. For some highly 
unscientific data, I've posted a poll on twitter: 
https://twitter.com/durin42/status/828742645145075712 - maybe we'll learn 
something.)

> The API looks pretty good to me. Nothing off the top of my head that I
> can add / question besides what I asked above.

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Sean Farley]

Augie Fackler  writes:

> (sending again because this seems to have gotten stuck somewhere...)
> (+yuya explicitly for chg thoughts, +smf so someone else can forward to the 
> list if it's stuck again)
>
> On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
>> # HG changeset patch
>> # User Bryan O'Sullivan 
>> # Date 1486160890 28800
>> #  Fri Feb 03 14:28:10 2017 -0800
>> # Node ID 30ee18bf947b97eca3582555f63eb3b2441e9db8
>> # Parent  abf029200e198878a4576a87e095bd8d77d9cea9
>> pager: migrate heavily-used extension into core
>> 
>> No default behaviours were harmed during the making of this change.
>> 
>> Note: this patch will break out-of-tree extensions that rely on the
>> location of the old pager module's attend variable.  It is now a
>> static variable named pagedcommands on the ui class.
>
> I've got feedback on this approach, which I'd like to talk out a bit
> before we either decide to land this or go on a v3 voyage. See below.
>
> If this is agreeable, I'll just push other things aside and do this,
> since it's something that we've got pretty clear consensus on, and I'm
> the one proposing a chunk of work to try and gild the lily.
>
> Sorry for how long this is - if you want, jump to the API sketch at
> the bottom and start from there, and look at my paragraph of rationale
> only if that looks bad?
>
>> 
>> diff --git a/mercurial/commands.py b/mercurial/commands.py
>> --- a/mercurial/commands.py
>> +++ b/mercurial/commands.py
>> @@ -107,6 +107,8 @@ globalopts = [
>> ('', 'version', None, _('output version information and exit')),
>> ('h', 'help', None, _('display help and exit')),
>> ('', 'hidden', False, _('consider hidden changesets')),
>> +('', 'pager', 'auto',
>> + _("when to paginate (boolean, always, auto, or never)"), _('TYPE')),
>> ]
>> 
>> dryrunopts = [('n', 'dry-run', None,
>> diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
>> --- a/mercurial/dispatch.py
>> +++ b/mercurial/dispatch.py
>> @@ -816,6 +816,39 @@ def _dispatch(req):
>> def _runcommand(ui, options, cmd, cmdfunc):
>> """Run a command function, possibly with profiling enabled."""
>> try:
>> +p = ui.config("pager", "pager", encoding.environ.get("PAGER"))
>> +usepager = ui.pageractive
>> +always = util.parsebool(options['pager'])
>> +auto = options['pager'] == 'auto'
>> +
>> +if not p or '--debugger' in sys.argv or not ui.formatted():
>> +pass
>> +elif always:
>> +usepager = True
>> +elif not auto:
>> +usepager = False
>> +else:
>> +attend = ui.configlist('pager', 'attend', ui.pagedcommands)
>> +ignore = ui.configlist('pager', 'ignore')
>> +cmds, _ = cmdutil.findcmd(cmd, commands.table)
>
> This bums me out as an approach, because it means that a command is
> necessarily always paged or always not paged, which is not always
> appropriate. The immediate example I can think of is shelve, which is
> multi-mode:
>
> `shelve --list --patch` -> definitely wants to be paged, this is
> likely a ton of output
>
> `shelve --interactive` -> is *broken* if a pager is in play.
>
> Rather than stick with the brute-force attend list in core, I'd like
> to move in the direction of adding a ui.pager() call to the ui object,
> which starts the pager. We'd then have a transitional period (a couple
> of releases?) where programmatically setting the attend list was
> supported in the old pager extension code, and then always support
> setting pager.attend to forcibly page commands which don't think they
> want pager love. This also plays reasonably well with chg, because it
> means that there's (still) a trivial point for chg to be told "start
> the pager now".
>
> My reason for wanting to move away from the attend list is the above,
> but also that it's hopelessly buggy in certain circumstances, like
> aliases, and it doesn't have a good affordance for new commands to
> specify default behavior (other than poking themselves in a list, but
> if the user has configured the attend list they no longer get the
> benefits of the sane defaults people hopefully put thought into).
>
> How does that sound, overall? I'll tackle the refactoring today or
> Wednesday to mail an RFC patch if that doesn't sound too much like the
> perfect being the enemy of the good.
>
> (This design, btw, was inspired by the way git handles paging, where
> it's largely up to the command to decide if it wants to invoke the
> pager.)

If I'm understanding you correctly, this will get rid of the
pager.attend variable? If that's true, then I fully support that.

> As a sketch of where this is headed, API-wise:
>
> class ui:
>  def pager(self, command, category):
>""Starts the pager, if desired by the user.
>
>`command` specifies the current command the user is running,
>something like `log` or `shelve`. It should be the whole original
>command 

Re: Gardening extensions

[Bryan O'Sullivan]

On Mon, Feb 6, 2017 at 1:45 PM, Kevin Bullock <
kbullock+mercur...@ringworld.org> wrote:

>
> Both of these are still extensions because they enable history editing. I
> recall discussions around moving these into core being predicated on evolve
> going in first. But phases are already in core, which provide one safety
> baseline for history editing...? Then again, phases don't prevent you
> losing work from a botched rebase, they only prevent you duplicating public
> changes.
>
> In principle, I'm +1 on moving them into core, but I'd like us to work out
> the safety implications for users in line with our established practice.
>

That's fair. At Facebook we now use hidden changesets to get rid of the old
commits instead of stripping, and this approach works well.

> * children - almost 10 years old, obsoleted by the children() revset
> function years ago.
>
> I'm not real enthused by the idea of a non-suppressible warning to stderr.
> I like our current approach of making the extension a dummy or shell around
> the newer core functionality. What's your reasoning for wanting a
> heavier-handed deprecation and removal cycle?
>

Well, my underlying assumption is that once these commands are in effect
gone, there's material value to deleting the rump extension code. For
example, doing so cuts startup time, which benefits everyone who enabled an
obsolete extension years ago and copypastas their hgrc around.

Consider the children extension, which has had the newer replacement
functionality documented for over a year. I'm assuming that people don't
read documentation or release notes, so if we agree that deleting the
extension makes sense, it seems preferable to nag them into using the new
thing before we delete the old.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Augie Fackler]

(sending again because this seems to have gotten stuck somewhere...)
(+yuya explicitly for chg thoughts, +smf so someone else can forward to the 
list if it's stuck again)

On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
> # HG changeset patch
> # User Bryan O'Sullivan 
> # Date 1486160890 28800
> #  Fri Feb 03 14:28:10 2017 -0800
> # Node ID 30ee18bf947b97eca3582555f63eb3b2441e9db8
> # Parent  abf029200e198878a4576a87e095bd8d77d9cea9
> pager: migrate heavily-used extension into core
> 
> No default behaviours were harmed during the making of this change.
> 
> Note: this patch will break out-of-tree extensions that rely on the
> location of the old pager module's attend variable.  It is now a
> static variable named pagedcommands on the ui class.

I've got feedback on this approach, which I'd like to talk out a bit
before we either decide to land this or go on a v3 voyage. See below.

If this is agreeable, I'll just push other things aside and do this,
since it's something that we've got pretty clear consensus on, and I'm
the one proposing a chunk of work to try and gild the lily.

Sorry for how long this is - if you want, jump to the API sketch at
the bottom and start from there, and look at my paragraph of rationale
only if that looks bad?

> 
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -107,6 +107,8 @@ globalopts = [
> ('', 'version', None, _('output version information and exit')),
> ('h', 'help', None, _('display help and exit')),
> ('', 'hidden', False, _('consider hidden changesets')),
> +('', 'pager', 'auto',
> + _("when to paginate (boolean, always, auto, or never)"), _('TYPE')),
> ]
> 
> dryrunopts = [('n', 'dry-run', None,
> diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
> --- a/mercurial/dispatch.py
> +++ b/mercurial/dispatch.py
> @@ -816,6 +816,39 @@ def _dispatch(req):
> def _runcommand(ui, options, cmd, cmdfunc):
> """Run a command function, possibly with profiling enabled."""
> try:
> +p = ui.config("pager", "pager", encoding.environ.get("PAGER"))
> +usepager = ui.pageractive
> +always = util.parsebool(options['pager'])
> +auto = options['pager'] == 'auto'
> +
> +if not p or '--debugger' in sys.argv or not ui.formatted():
> +pass
> +elif always:
> +usepager = True
> +elif not auto:
> +usepager = False
> +else:
> +attend = ui.configlist('pager', 'attend', ui.pagedcommands)
> +ignore = ui.configlist('pager', 'ignore')
> +cmds, _ = cmdutil.findcmd(cmd, commands.table)

This bums me out as an approach, because it means that a command is
necessarily always paged or always not paged, which is not always
appropriate. The immediate example I can think of is shelve, which is
multi-mode:

`shelve --list --patch` -> definitely wants to be paged, this is
likely a ton of output

`shelve --interactive` -> is *broken* if a pager is in play.

Rather than stick with the brute-force attend list in core, I'd like
to move in the direction of adding a ui.pager() call to the ui object,
which starts the pager. We'd then have a transitional period (a couple
of releases?) where programmatically setting the attend list was
supported in the old pager extension code, and then always support
setting pager.attend to forcibly page commands which don't think they
want pager love. This also plays reasonably well with chg, because it
means that there's (still) a trivial point for chg to be told "start
the pager now".

My reason for wanting to move away from the attend list is the above,
but also that it's hopelessly buggy in certain circumstances, like
aliases, and it doesn't have a good affordance for new commands to
specify default behavior (other than poking themselves in a list, but
if the user has configured the attend list they no longer get the
benefits of the sane defaults people hopefully put thought into).

How does that sound, overall? I'll tackle the refactoring today or
Wednesday to mail an RFC patch if that doesn't sound too much like the
perfect being the enemy of the good.

(This design, btw, was inspired by the way git handles paging, where
it's largely up to the command to decide if it wants to invoke the
pager.)



As a sketch of where this is headed, API-wise:

class ui:
 def pager(self, command, category):
   ""Starts the pager, if desired by the user.

   `command` specifies the current command the user is running,
   something like `log` or `shelve`. It should be the whole original
   command name, not the partial name or alias name.

   `category` specifies a broad category this pager invocation fits
   into. Examples include `diff`, `log`, `status`, `help`. This
   allows users to disable paging of entire types of commands easily.
   """
   # pager starts, self.pageractive=true, etc

@command
def shelve(ui, 

Re: Backwards compatibility before all else? [was Re: [PATCH v2] pager: migrate heavily-used extension into core]

[Sean Farley]

Bryan O'Sullivan  writes:

> On Sun, Feb 5, 2017 at 7:24 PM, Augie Fackler  wrote:
>
>>
>> > I'm inclined to *not* add special code to see if the old pager extension
>> has been disabled. That's achievable by disabling the pager instead. This
>> would require a release note, of course (just in case anyone reads them).
>>
>> I’m conflicted here: I’ve been chasing my tail on a problem with emacs
>> tramp-mode for months, and finally root-caused it to a missing flag in my
>> pager settings for less, only triggered by emacs running hg over ssh. It
>> was pretty baffling.
>>
>> On the other hand, it’s clearly the most-right choice to have the pager on
>> as part of the recommended configuration. I’ve been using it (as an
>> experiment) at work for over a year, and I’ve finally gotten used to it and
>> (for the most part) like it.
>>
>> What do other people think?
>>
>
> Well, this is an interesting case of a bigger pattern.
>
> To be honest, I think that the long-time insistence on (and acquiescence
> to) backwards compatibility for every little aspect of behaviour for all
> eternity has been extremely stifling. The fact that git users have thrived
> despite a decade of occasional incompatible changes (including enabling
> pager use by default) suggests that the compatibility-before-all
> perspective wasn't ever really prioritised correctly in the first place.
>
> I think that the community would do well to slightly loosen its standards
> for breaking changes. Yes, such changes will cause occasional problems for
> a small number of people, but the alternative of stagnation isn't super
> appealing.

This resonates so very much with me.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Backwards compatibility before all else? [was Re: [PATCH v2] pager: migrate heavily-used extension into core]

[Kevin Bullock]

> On Feb 6, 2017, at 14:00, Bryan O'Sullivan  wrote:
> 
> Well, this is an interesting case of a bigger pattern.
> 
> To be honest, I think that the long-time insistence on (and acquiescence to) 
> backwards compatibility for every little aspect of behaviour for all eternity 
> has been extremely stifling. The fact that git users have thrived despite a 
> decade of occasional incompatible changes (including enabling pager use by 
> default) suggests that the compatibility-before-all perspective wasn't ever 
> really prioritised correctly in the first place.
> 
> I think that the community would do well to slightly loosen its standards for 
> breaking changes. Yes, such changes will cause occasional problems for a 
> small number of people, but the alternative of stagnation isn't super 
> appealing.

I for one still generally agree with the strong emphasis we've always placed on 
backward compatibility. I think there's a pretty well-established, if subtle, 
set of distinctions that we've made about different kinds of backward 
compatibility, though. Some of them have been more strongly guarded than 
others, so we should be clear on what we're discussing if we want to change our 
approach.

First, there's compatibility of on-disk repositories and the wire protocol: new 
versions should always be able to interact with old repos. This is one of the 
strongest guarantees we maintain.

Second, there's stability of the command-line output. The degree to which this 
is guarded depends on the command, namely on how likely it is to be used in 
everyone's janky scripts.

And so on, for a bunch more categories that are listed on 
 and more that probably 
aren't.

Anyway, these things often ultimately come down to a case-by-case judgement 
call, and I suspect that the current reviewers will tend to fall a bit less 
often on the side of keeping things static than Matt did. But I think the case 
still needs to be made clearly as to the benefit vs. potential for breakage of 
any particular change.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: for 4.2 sprint, accommodations around Moutain View

[Sean Farley]

Martin von Zweigbergk via Mercurial-devel
 writes:

> On Fri, Feb 3, 2017 at 10:15 AM FUJIWARA Katsunori 
> wrote:
>
>> Hi, devels
>>
>> Now, I'm looking for accommodations for upcoming 4.2 sprint, and
>> surprised by high price hotel fee in Mountain View :-)
>>
>
> Yes :-(
>
>
>>
>> Would you have any information about:
>>
>>   - reasonable (often used) accommodations for events at google in
>> Mountain View
>>
>
> I don't know much about this, sorry. I stayed at Hotel Avante when I
> interviewed here ~6 years ago. I was happy with it. It's very close to
> where I now live, so if anyone decides to stay there, I could probably
> drive 3-4 of them from there to the office.
>
> I should also say that it has turned out to be much harder than I had
> expected to find a large conference room anywhere in Mountain View or
> Sunnyvale. It's still unclear exactly where it will be, but in will be
> somewhere around the Googleplex
> 
> or
> the Tech Corners
> 
>  area.
>
>
>>
>>   - which (public) traffics are convenience around Mountain View
>>
>
> It's pretty bad here. I checked how to get from my home (just as an
> example) to Googleplex. It's 11 minutes by car and 1 hour by transit.
> However, if the event ends up being in the Tech Corners area, then the
> light rail should be a decent option (the Moffet Park stop) if you can stay
> somewhere close to one of its other stops, such as downtown Mountain View.

I think we should set up (perhaps on the wiki) people driving from the
city. I can pick up 4 passengers on my way down. I know Erik has a car
so I think we could make something work with shuttling people that way.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH RFC] contrib: script to generate release notes from commit messages

[Sean Farley]

Gregory Szorc  writes:

> On Fri, Feb 3, 2017 at 12:40 AM, Denis Laxalde 
> wrote:
>
>> Gregory Szorc a écrit :
>>
>>> # HG changeset patch
>>> # User Gregory Szorc 
>>> # Date 1486108530 28800
>>> #  Thu Feb 02 23:55:30 2017 -0800
>>> # Node ID 5fe78521b9cb553b9a7c6bd4d96576a35b8d3517
>>> # Parent  abf029200e198878a4576a87e095bd8d77d9cea9
>>> contrib: script to generate release notes from commit messages
>>>
>>
>> [snip]
>>
>>
>> diff --git a/tests/test-generate-release-notes.t
>>> b/tests/test-generate-release-notes.t
>>> new file mode 100644
>>> --- /dev/null
>>> +++ b/tests/test-generate-release-notes.t
>>> @@ -0,0 +1,145 @@
>>> +Create a fake repo with a relnotes directory and commits
>>> +
>>> +  $ hg init repo0
>>> +  $ export FAKESRCDIR=$TESTTMP/repo0
>>> +  $ cd repo0
>>> +  $ mkdir relnotes
>>> +  $ touch relnotes/4.1.rst
>>> +  $ hg commit -A -m 'add relnotes 4.1'
>>> +  adding relnotes/4.1.rst
>>> +
>>> +4.1.rst should be used for relnotes if only available file
>>> +
>>> +  $ $TESTDIR/../contrib/generate-release-notes
>>> +  updating $TESTTMP/repo0/relnotes/4.1.rst with content from 1
>>> changesets
>>> +
>>> +4.1.1.rst is used over 4.1.rst
>>> +
>>> +  $ touch relnotes/4.1.1.rst
>>> +  $ hg commit -A -m 'add relnotes 4.1.1'
>>> +  adding relnotes/4.1.1.rst
>>> +  $ $TESTDIR/../contrib/generate-release-notes
>>> +  updating $TESTTMP/repo0/relnotes/4.1.1.rst with content from 2
>>> changesets
>>> +
>>> +4.2 is used over 4.1.1
>>> +
>>> +  $ touch relnotes/4.2.rst
>>> +  $ hg commit -A -m 'add relnotes 4.2'
>>> +  adding relnotes/4.2.rst
>>> +  $ $TESTDIR/../contrib/generate-release-notes
>>> +  updating $TESTTMP/repo0/relnotes/4.2.rst with content from 3
>>> changesets
>>> +
>>> +A fix with a single line is documented with .. fix::
>>> +
>>> +  $ touch fix1
>>> +  $ hg commit -A -l - << EOF
>>> +  > summary line
>>> +  >
>>> +  > .. fix::
>>> +  >
>>> +  > this is a simple fix with a single line
>>> +  > EOF
>>>
>>
>> I looks strange to have an rst block body that is not indented. Typically
>> this is not valid rst as the "fix" directive has no content block here. So
>> maybe we should consider indentation? That would also make it possible to
>> have more text after a directive like:
>>
>> .. fix::
>>
>> this is a simple fix with a single line
>>
>> more content not to be part of the release notes.
>>
>
> Yes, that is a good suggestion. It also makes the parser simpler since you
> can just look for indented lines.
>
> I'd still like positive feedback from others before I finish this patch: I
> don't want to sink more time in it before there is buy-in to this approach.

I like the idea of using mailing list (as a review of text) + commit
message but as Sid mentioned, we will still need to copy/edit. It's
inevitable since we're human.

So, as a source of text, the commit message makes sense. But how will we
solve copy editing?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Evolve naming troubles

[Sean Farley]

Pierre-Yves David  writes:

> On 01/20/2017 07:11 PM, Sean Farley wrote:
>> While we are in a freeze and have some time to think about things
>> outside of features, I'd like to bring up naming evolution terms before
>> they are permanently frozen.
>>
>> I'll keep this mostly short with a list of current names and suggested
>> replacements but I hope we can finalize this at the next sprint. The
>> following suggestions are from an IRC a little while ago.
>
> Thanks you very much, for looking into this and starting this thread.
>
> I've spent some time today to build a wiki page to gather the result of 
> that discussion: https://www.mercurial-scm.org/wiki/CEDVocabulary
>
> I've also reached out to "Timeless" to act as a "word expert" on this. 
> The idea is to build a small group of people willing to dissect the 
> semantic and etymology of all proposals. The goal is to prepare and 
> curate the list we'll have to discuss at the sprint. Reach out to me if 
> you are interested in spending time doing such analysis (I'm contacting 
> Sean too).
>
> I'll spend more time this week to:
>   * make a clean-up pass on the definition of that page,
>   * update the page with reply from this thread (feel free to do it 
> yourself as you reply),
>   * give my own opinion on the proposals,

Thanks for making a wiki; should be helpful during the sprint. Should we
keep discussing on the mailing list?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Gardening extensions

[Kevin Bullock]

> On Feb 6, 2017, at 14:44, Bryan O'Sullivan  wrote:
> 
> Not surprisingly, the pager extension isn't the only one in my sights at the 
> moment.
> 
> Here are a few others I've been thinking about.
> 
> Proposals to move into core:
> 
> * color - approaching its tenth anniversary, and widely used.

+1

> * histedit - widely used for 5+ years.
> 
> * rebase - almost a decode old, widely used.

Both of these are still extensions because they enable history editing. I 
recall discussions around moving these into core being predicated on evolve 
going in first. But phases are already in core, which provide one safety 
baseline for history editing...? Then again, phases don't prevent you losing 
work from a botched rebase, they only prevent you duplicating public changes.

In principle, I'm +1 on moving them into core, but I'd like us to work out the 
safety implications for users in line with our established practice.

> Extensions to delete: for each of these, I propose adding a non-suppressible 
> warning to stderr that it'll be deleted, keeping that around for one or two 
> release cycles, then deleting the extension.

> 
> * children - almost 10 years old, obsoleted by the children() revset function 
> years ago.

I'm not real enthused by the idea of a non-suppressible warning to stderr. I 
like our current approach of making the extension a dummy or shell around the 
newer core functionality. What's your reasoning for wanting a heavier-handed 
deprecation and removal cycle?

> * graphlog - its functionality has been in core hg for almost 5 years.

Same deal here, this is already a very simple wrapper around `hg log -G`.

> * record - obsoleted by crecord.

Err... to be more accurate, obsoleted by `hg commit -i`, which now also has a 
curses mode. But of course that's what you meant. ;)

> * transplant - sadly not entirely obsoleted by rebase, but kind of an 
> obscenity anyway :-) (actually I just included this to see who reads this far)

It would be great to see `hg graft` grow the ability to graft from a remote 
repo. I believe that's the only reason transplant still exists.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Gardening extensions

[Sean Farley]

Bryan O'Sullivan  writes:

> Not surprisingly, the pager extension isn't the only one in my sights at
> the moment.
>
> Here are a few others I've been thinking about.
>
> Proposals to move into core:
>
> * color - approaching its tenth anniversary, and widely used.

Yep.

> * histedit - widely used for 5+ years.

Nice.

> * rebase - almost a decode old, widely used.

Oh, yeah.

> Extensions to delete: for each of these, I propose adding a
> non-suppressible warning to stderr that it'll be deleted, keeping that
> around for one or two release cycles, then deleting the extension.
>
> * children - almost 10 years old, obsoleted by the children() revset
> function years ago.

Makes sense.

> * graphlog - its functionality has been in core hg for almost 5 years.

I agree.

> * record - obsoleted by crecord.

Is it? I thought there was something missing but I honestly can't
remember.

> * transplant - sadly not entirely obsoleted by rebase, but kind of an
> obscenity anyway :-) (actually I just included this to see who reads this
> far)

I guess you meant 'graft'? The only thing that transplant does that
graft does not is the ability to work across two different repos. I
believe that might have been my first patch to Mercurial and mpm said
he'd prefer to nix transplant usage in favor of 'hg export | hg import
-' so I would say this extension should definitely go :-)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Gardening extensions

[Bryan O'Sullivan]

Not surprisingly, the pager extension isn't the only one in my sights at
the moment.

Here are a few others I've been thinking about.

Proposals to move into core:

* color - approaching its tenth anniversary, and widely used.

* histedit - widely used for 5+ years.

* rebase - almost a decode old, widely used.

Extensions to delete: for each of these, I propose adding a
non-suppressible warning to stderr that it'll be deleted, keeping that
around for one or two release cycles, then deleting the extension.

* children - almost 10 years old, obsoleted by the children() revset
function years ago.

* graphlog - its functionality has been in core hg for almost 5 years.

* record - obsoleted by crecord.

* transplant - sadly not entirely obsoleted by rebase, but kind of an
obscenity anyway :-) (actually I just included this to see who reads this
far)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] match: adding non-recursive directory matching

[Rodrigo Damazio via Mercurial-devel]

On Sun, Feb 5, 2017 at 4:01 AM, FUJIWARA Katsunori 
wrote:

> At Fri, 3 Feb 2017 20:26:04 -0800,
> Rodrigo Damazio wrote:
> >
> > [1  ]
> > [1.1  ]
> > Finally working on this again.
> > On point which I discussed with Martin offline - which feels more
> intuitive
> > as a prefix, "root" or "abs"? (so, "rootfilesin" or "absfilesin"?) We
> think
> > it's "abs", but wanted to make sure that's OK with others.
>
> In FileNamePatternsPlan page, I choose "root" as a name of point, to
> which patterns are relative ("root", "cwd", and "any").
>
> I'm OK with "abs", if other thinks that it is more intuitive for
> "relative to the root".
>

Alright, I'll keep "root", it sounds more consistent when put that way.
(Augie also seems to prefer root)

BTW, are "cwd" and "any" prefixes are OK with "abs" ?


> > Thanks
> >
> >
> > On Sun, Jan 29, 2017 at 3:15 AM, FUJIWARA Katsunori <
> fo...@lares.dti.ne.jp>
> > wrote:
> >
> > >
> > > At Fri, 27 Jan 2017 15:14:38 -0800,
> > > Rodrigo Damazio wrote:
> > > >
> > > > [1  ]
> > > > [1.1  ]
> > > > On Fri, Jan 27, 2017 at 1:03 AM, FUJIWARA Katsunori <
> > > fo...@lares.dti.ne.jp>
> > > > wrote:
> > > >
> > > > >
> > > > > At Thu, 26 Jan 2017 17:27:17 -0800,
> > > > > Rodrigo Damazio wrote:
> > > > > >
> > > > > > [1  ]
> > > > > > [1.1  ]
> > > > > > All sounds very reasonable, and "filesin:" or "rootfilesin:"
> LGTM.
> > > > >
> > > > > Is it OK for your solution that "rootfilesin:FOO" doesn't match
> > > > > against "file FOO", even though your patch posted in this thread
> made
> > > > > "files:FOO" do so ? or, is combining "rootfile:" and "rootfilesin"
> > > > > acceptable for your solution ?
> > > > >
> > > >
> > > > Yes, not matching files is fine, and actually the easiest to
> implement
> > > (the
> > > > regex is simpler and our custom server doesn't support files anyway).
> > > > For that, rootfilesin:foo/bar can produce regex ^foo/bar/[^/]+$ or
> > > similar
> > > > which would not match a file called bar. visitdir would have to be
> > > updated
> > > > accordingly, of course, but that shouldn't be too hard (and i can
> take
> > > the
> > > > opportunity to add some comments to the code).
> > > >
> > > > If that looks good to you, let me know and I'll send an updated
> patch.
> > >
> > > Sure, LGTM
> > >
> > > --
> > > --
> > > [FUJIWARA Katsunori] fo...@lares.dti.ne.jp
> > >
> > [1.2  ]
> >
> > [2 S/MIME Cryptographic Signature ]
> >
>
> --
> --
> [FUJIWARA Katsunori] fo...@lares.dti.ne.jp
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Backwards compatibility before all else? [was Re: [PATCH v2] pager: migrate heavily-used extension into core]

[Augie Fackler]

> On Feb 6, 2017, at 15:00, Bryan O'Sullivan  wrote:
> 
> On Sun, Feb 5, 2017 at 7:24 PM, Augie Fackler  wrote:
> 
> > I'm inclined to *not* add special code to see if the old pager extension 
> > has been disabled. That's achievable by disabling the pager instead. This 
> > would require a release note, of course (just in case anyone reads them).
> 
> I’m conflicted here: I’ve been chasing my tail on a problem with emacs 
> tramp-mode for months, and finally root-caused it to a missing flag in my 
> pager settings for less, only triggered by emacs running hg over ssh. It was 
> pretty baffling.
> 
> On the other hand, it’s clearly the most-right choice to have the pager on as 
> part of the recommended configuration. I’ve been using it (as an experiment) 
> at work for over a year, and I’ve finally gotten used to it and (for the most 
> part) like it.
> 
> What do other people think?
> 
> Well, this is an interesting case of a bigger pattern.
> 
> To be honest, I think that the long-time insistence on (and acquiescence to) 
> backwards compatibility for every little aspect of behaviour for all eternity 
> has been extremely stifling. The fact that git users have thrived despite a 
> decade of occasional incompatible changes (including enabling pager use by 
> default) suggests that the compatibility-before-all perspective wasn't ever 
> really prioritised correctly in the first place.
> 
> I think that the community would do well to slightly loosen its standards for 
> breaking changes. Yes, such changes will cause occasional problems for a 
> small number of people, but the alternative of stagnation isn't super 
> appealing.

As a general principle, I agree. I think we'll have to take it on a 
case-by-case basis though: I'd like to avoid things that would cause widespread 
carnage in scripts that have been built over the years using sh scripts, 
chewing gum, and bailing wire.

(My bias on the pager thing, btw, is to go with it, and try and encourage some 
widespread testing early in the cycle to try and sniff out any problems. It's 
rough in this case because our biggest captive tester audiences already default 
the pager to enabled.)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Backwards compatibility before all else? [was Re: [PATCH v2] pager: migrate heavily-used extension into core]

[Bryan O'Sullivan]

On Sun, Feb 5, 2017 at 7:24 PM, Augie Fackler  wrote:

>
> > I'm inclined to *not* add special code to see if the old pager extension
> has been disabled. That's achievable by disabling the pager instead. This
> would require a release note, of course (just in case anyone reads them).
>
> I’m conflicted here: I’ve been chasing my tail on a problem with emacs
> tramp-mode for months, and finally root-caused it to a missing flag in my
> pager settings for less, only triggered by emacs running hg over ssh. It
> was pretty baffling.
>
> On the other hand, it’s clearly the most-right choice to have the pager on
> as part of the recommended configuration. I’ve been using it (as an
> experiment) at work for over a year, and I’ve finally gotten used to it and
> (for the most part) like it.
>
> What do other people think?
>

Well, this is an interesting case of a bigger pattern.

To be honest, I think that the long-time insistence on (and acquiescence
to) backwards compatibility for every little aspect of behaviour for all
eternity has been extremely stifling. The fact that git users have thrived
despite a decade of occasional incompatible changes (including enabling
pager use by default) suggests that the compatibility-before-all
perspective wasn't ever really prioritised correctly in the first place.

I think that the community would do well to slightly loosen its standards
for breaking changes. Yes, such changes will cause occasional problems for
a small number of people, but the alternative of stagnation isn't super
appealing.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Making chg stateful

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-02-05 13:59:32 +0900:
> Perhaps that is a matter of taste, I like the explicit one. But I heard
> Python 3 has a generator-based coroutine, so using "yield" for that purpose
> is more common in Python 3?
>
> @preload('index')
> def preloadindex(repo):
> f = repo.svfs('changelog.i') # "f" can be shared naturally
> hash = fstat(f).st_size
> def loadindex():
> indexdata = f.read()
> hash = len(indexdata)
> return parseindex(indexdata), hash

The inner "loadindex" function makes things unnecessarily more complex in my
opinion. It makes the final return type harder to read, introduces extra
indentation and a function definition.

If the goal is to get rid of "yield", it could be done in different ways.
For example,

Choice A: explicitly pass oldhash and the oldobject. We probably need
the old object anyway to allow incremental updates:

@preload('obsstore', depend=['changelog'])
def preloadobsstore(repo, oldhash, oldobsstore):
obsstore = oldobsstore
newhash = ...
if newhash != oldhash:
 # note: this is an indentation not existed using yield
obsstore = ...
return newhash, obsstore

Choice B: just give the preload function access to the cache object:

@preload(['obsstore', 'changelog'])
def preloadmultiple(repo, cache):
oldhash, oldobsstore = cache['obsstore']


Choice A looks simple. Choice B is more expressive while the function body
could be out of control - ex. it could skip setting cache['obsstore'] even
if it says so in its decorator.

While Choice A may serve most requirements just well, I think "yield" is
more expressive, and avoid unnecessary indentation. For example, the
following could not be expressed using "return" cleanly and easily:

- Optional dependency:

  if fastpath_cannot_work:
 yield preload.require('changelog')

  Maybe "raise MissingRequirement('changelog')", but that makes
  the function "restarted", while the generator could continue
  executing without losing context.

- Optionally change the cache key:

  As mentioned in "4)", [1]

Therefore I think the generator way avoids all kinds of indentations
(reminds me of nodejs callback hell), and has better extensibility. So I
currently prefer it. Otherwise the "Choice A" may be good enough for now.
The code base has already used "yield" for its future implementation used
for batched remote peer calls.

[1] 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/092584.html

> return hash, loadindex
> 
> BTW, when will 'f' be closed if we take the generator-based abstraction?
>
> def preloadindex(repo):
> f = repo.svfs('changelog.i')
> try:
> yield ...
> yield ...
> finally:
> f.close()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH v3 rebased] pager: migrate heavily-used extension into core

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1486160890 28800
#  Fri Feb 03 14:28:10 2017 -0800
# Node ID ae22925dafd4a270cb80a7bb54c9d70bce49a633
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
pager: migrate heavily-used extension into core

No default behaviours were harmed during the making of this change.

Notes:

* This patch will break out-of-tree extensions that rely on the
  location of the old pager module's attend variable.  It is now a
  static variable named pagercommands on the ui class.

* It used to be possible to disable the pager via config by disabling
  the loading of the extension.  With the extension gone, that
  method no longer works.  Instead, set pager.attend to a command
  that does not exist, e.g. "--config pager.attend=nothing".

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -107,6 +107,8 @@ globalopts = [
 ('', 'version', None, _('output version information and exit')),
 ('h', 'help', None, _('display help and exit')),
 ('', 'hidden', False, _('consider hidden changesets')),
+('', 'pager', 'auto',
+ _("when to paginate (boolean, always, auto, or never)"), _('TYPE')),
 ]
 
 dryrunopts = [('n', 'dry-run', None,
diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
--- a/mercurial/dispatch.py
+++ b/mercurial/dispatch.py
@@ -816,6 +816,37 @@ def _dispatch(req):
 def _runcommand(ui, options, cmd, cmdfunc):
 """Run a command function, possibly with profiling enabled."""
 try:
+p = ui.config("pager", "pager", encoding.environ.get("PAGER"))
+usepager = ui.pageractive
+always = util.parsebool(options['pager'])
+auto = options['pager'] == 'auto'
+
+if not p or '--debugger' in sys.argv or not ui.formatted():
+pass
+elif always:
+usepager = True
+elif not auto:
+usepager = False
+else:
+attend = ui.configlist('pager', 'attend', ui.pagercommands)
+ignore = ui.configlist('pager', 'ignore')
+cmds, _ = cmdutil.findcmd(cmd, commands.table)
+
+for cmd in cmds:
+var = 'attend-%s' % cmd
+if ui.config('pager', var):
+usepager = ui.configbool('pager', var)
+break
+if cmd in attend or (cmd not in ignore and not attend):
+usepager = True
+break
+
+ui.pageractive = usepager
+
+if usepager:
+ui.setconfig('ui', 'formatted', ui.formatted(), 'pager')
+ui.setconfig('ui', 'interactive', False, 'pager')
+ui._runpager(p)
 return cmdfunc()
 except error.SignatureError:
 raise error.CommandError(cmd, _('invalid arguments'))
diff --git a/mercurial/extensions.py b/mercurial/extensions.py
--- a/mercurial/extensions.py
+++ b/mercurial/extensions.py
@@ -27,7 +27,7 @@ from . import (
 _aftercallbacks = {}
 _order = []
 _builtin = set(['hbisect', 'bookmarks', 'parentrevspec', 'progress', 'interhg',
-'inotify', 'hgcia'])
+'inotify', 'hgcia', 'pager'])
 
 def extensions(ui=None):
 if ui:
diff --git a/mercurial/help.py b/mercurial/help.py
--- a/mercurial/help.py
+++ b/mercurial/help.py
@@ -230,6 +230,7 @@ helptable = sorted([
  loaddoc('scripting')),
 (['internals'], _("Technical implementation topics"),
  internalshelp),
+(["pager"], _("Using an External Pager"), loaddoc('pager')),
 ])
 
 # Maps topics with sub-topics to a list of their sub-topics.
diff --git a/hgext/pager.py b/mercurial/help/pager.txt
rename from hgext/pager.py
rename to mercurial/help/pager.txt
--- a/hgext/pager.py
+++ b/mercurial/help/pager.txt
@@ -1,19 +1,3 @@
-# pager.py - display output using a pager
-#
-# Copyright 2008 David Soria Parra 
-#
-# This software may be used and distributed according to the terms of the
-# GNU General Public License version 2 or any later version.
-#
-# To load the extension, add it to your configuration file:
-#
-#   [extension]
-#   pager =
-#
-# Run 'hg help pager' to get info on configuration.
-
-'''browse command output with an external pager
-
 To set the pager that should be used, set the application variable::
 
   [pager]
@@ -56,117 +40,3 @@ you can use --pager=::
   - require the pager: `yes` or `on`.
   - suppress the pager: `no` or `off` (any unrecognized value
   will also work).
-
-'''
-from __future__ import absolute_import
-
-import atexit
-import os
-import signal
-import subprocess
-import sys
-
-from mercurial.i18n import _
-from mercurial import (
-cmdutil,
-commands,
-dispatch,
-encoding,
-extensions,
-util,
-)
-
-# Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' 
for
-# extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
-# be specifying the version(s) of Mercurial they are tested with, 

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Bryan O'Sullivan]

On Mon, Feb 6, 2017 at 9:44 AM, Augie Fackler  wrote:

> Yes, we should definitely make pager easier to use. My own informal
> surveys of users are that even a setting in hgrc would be better than an
> extension, because there's a perception that an extension is somehow
> dangerous.
>

Not only that, but extensions are significantly more costly than built-in
code, because they have to be loaded eagerly so that they can commit all
their myriad sins during startup.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] smartset: move set classes and related functions from revset module (API)

[Sean Farley]

Yuya Nishihara  writes:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1476606531 -32400
> #  Sun Oct 16 17:28:51 2016 +0900
> # Node ID a555e941ebe982cc22e15670bfe125017b3121e5
> # Parent  8d7e40524ae467b3201e264e3548681c52bb6492
> smartset: move set classes and related functions from revset module (API)
>
> These classes are pretty large and independent from revset computation.
>
>   2961 mercurial/revset.py
>973 mercurial/smartset.py
>   3934 total
>
> revset.prettyformatset() is renamed to smartset.prettyformat(). Smartset
> classes are aliased since they are quite common in revset.py.

Love it. Plz moar cleanup!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2 remotenames-ext v2] lazyremotenamedict: rename resolvekeys to resolvenodes

[Sean Farley]

Kostia Balytskyi  writes:

> # HG changeset patch
> # User Kostia Balytskyi 
> # Date 1486377812 28800
> #  Mon Feb 06 02:43:32 2017 -0800
> # Node ID b6b0363782555a9acc98c79c25aa7b1c38ece709
> # Parent  f7a3dffec18438cffeef930c8e2ed4f2da0bd4bb
> lazyremotenamedict: rename resolvekeys to resolvenodes
>
> I think my initial decision to call it resolvekeys was a mistake.
> Resolvenodes is clearer becuase the meaning is clearly hg-related
> instead of dict-related.

Thanks! Queued!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Google Summer of Code 2017.

[Augie Fackler]

> On Feb 5, 2017, at 18:45, Pulkit Goyal <7895pul...@gmail.com> wrote:
> 
> The wiki page for Python GSoC 2017 states that interested organisations need 
> to apply as a sub-org before 8th Feb[1]. Taking part under the Python 
> Software Foundation umbrella will be good, we participated last time the same 
> way. So the deadline is very close.
> 
> To speed up things, we need an `admin` who can manage GSoC stuff.  I can be 
> an admin(yes, I am not participating as a student again :)​ ​) in case nobody 
> else is ready.

If you're willing to be admin, then yes, go ahead and reach out to the Python 
people and see if they're willing to have us participate. If you need a backup 
admin (I think you do?), I can probably do that, depending on the schedule.

Thanks!

> 
> [1] http://python-gsoc.org/#schedule
> 
> On Sat, Feb 4, 2017 at 2:26 PM, Pulkit Goyal <7895pul...@gmail.com> wrote:
> Hello everyone,
> 
> Google Summer of Code 2016 was a good experience for both me and
> Piotr. We learned a lot. With GSoC 2017 near, students have started
> asking me about Mercurial taking part in GSoC 2017.
> 
> Taking part in GSoC is good as we get new contributors (I am one of
> them). Are we going to take part in GSoC 2017?
> 
> Regards
> Pulkit Goyal
> 
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH v2] pager: migrate heavily-used extension into core

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-02-05 22:24:39 -0500:
> > On Sun, Feb 5, 2017 at 1:44 AM, Yuya Nishihara  wrote:
> > I like the direction of this patch, but this still involves a behavior
> > change. If PAGER variable is set but pager extension disabled, pager will
> > be started wrongly.
> > 
> > I'm inclined to *not* add special code to see if the old pager extension
> > has been disabled. That's achievable by disabling the pager instead.
> > This would require a release note, of course (just in case anyone reads
> > them).
> I’m conflicted here: I’ve been chasing my tail on a problem with emacs
> tramp-mode for months, and finally root-caused it to a missing flag in my
> pager settings for less, only triggered by emacs running hg over ssh. It
> was pretty baffling.

I guess the TTY check could prevent pager from running incorrectly?

> On the other hand, it’s clearly the most-right choice to have the pager on
> as part of the recommended configuration. I’ve been using it (as an
> experiment) at work for over a year, and I’ve finally gotten used to it
> and (for the most part) like it.
> 
> What do other people think?

I think the point of moving pager to core is to make it more accessible.
If a new user only needs to set PAGER without touching .hgrc to use a pager,
that sounds like a step forward to me.

If BC is a concern, some temporary deprecation warnings might be helpful.

The patch seems to conflict with Simon's stdout change - a rebase is
probably needed. Otherwise it looks good to me, I have especially checked
chg compatibility.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 08 of 10 shelve-ext v3] shelve: add obs-based unshelve functionality

[Kostia Balytskyi]

On 03/02/2017 23:17, Sean Farley wrote:

> Kostia Balytskyi  writes:
>
>> # HG changeset patch
>> # User Kostia Balytskyi 
>> # Date 1484835394 28800
>> #  Thu Jan 19 06:16:34 2017 -0800
>> # Node ID 94a237a046059ef246aacb2c3ad809c9f0bdbe70
>> # Parent  abdf9565fdce15604ea4abf013cb7c98a11f70ca
>> shelve: add obs-based unshelve functionality
>>
>> Obsolescense-based unshelve works as follows:
>> 1. Instead of stripping temporary nodes, markers are created to
>> obsolete them.
>> 2. Restoring commit is just finding it in an unfiltered repo.
>> 3. '--keep' is only passed to rebase on traditional unshelves
>> (and thus traditional rebases), becuase we want markers to be
>> created fro obsolete-based rebases.
>> 4. 'hg unshelve' uses unfiltered repo to perform rebases
>> because we want rebase to be able to create markers between original
>> and new commits. 'rebaseskipobsolete' is disabled to make rebase not
>> skip the commit altogether.
> Before this gets into core, can we not implement stripping obs markers?
> This seems like a good use-case for such functionality.
I am not sure I understand why stripping obs-markers is a pre-requisite 
here. Can you explain?

FWIW, you can strip obs-markers like this: 'hg debugobsolete --delete 
7', where 7 is a maker index which can be learned by running 'hg 
debugobsolete --index'.
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2 remotenames-ext v2] lazyremotenamedict: rename resolvekeys to resolvenodes

[Kostia Balytskyi]

# HG changeset patch
# User Kostia Balytskyi 
# Date 1486377812 28800
#  Mon Feb 06 02:43:32 2017 -0800
# Node ID b6b0363782555a9acc98c79c25aa7b1c38ece709
# Parent  f7a3dffec18438cffeef930c8e2ed4f2da0bd4bb
lazyremotenamedict: rename resolvekeys to resolvenodes

I think my initial decision to call it resolvekeys was a mistake.
Resolvenodes is clearer becuase the meaning is clearly hg-related
instead of dict-related.

diff --git a/remotenames.py b/remotenames.py
--- a/remotenames.py
+++ b/remotenames.py
@@ -347,37 +347,37 @@ class lazyremotenamedict(UserDict.DictMi
 else:
 return None
 
-def keys(self, resolvekeys=None):
+def keys(self, resolvenodes=None):
 """Get a list of bookmark names
 
-`resolvekeys` allows callee to ask whether nodes to which these keys
+`resolvenodes` allows callee to ask whether nodes to which these keys
 point should be resolved in a revlog (to safeguard against a key
 pointing to a non-existent node). If this kwarg:
-- is None: remotenames.resolvekeys config value is read,
+- is None: remotenames.resolvenodes config value is read,
   defaulting to True, as the behavior before this fix
-- is not None: the bool value of resolvekeys is used"""
-if resolvekeys is None:
-resolvekeys = self._repo.ui.configbool("remotenames",
-   "resolvekeys", True)
+- is not None: the bool value of resolvenodes is used"""
+if resolvenodes is None:
+resolvenodes = self._repo.ui.configbool("remotenames",
+   "resolvenodes", True)
 if not self.loaded:
 self._load()
-if resolvekeys:
+if resolvenodes:
 for u in self.potentialentries.keys():
 self._fetchandcache(u)
 return self.cache.keys()
 return self.potentialentries.keys()
 
-def iteritems(self, resolvekeys=None):
+def iteritems(self, resolvenodes=None):
 """Iterate over (name, node) tuples
 
-`resolvekeys` has the same meaning as in `keys()` method"""
+`resolvenodes` has the same meaning as in `keys()` method"""
 if not self.loaded:
 self._load()
-if resolvekeys is None:
-resolvekeys = self._repo.ui.configbool("remotenames",
-   "resolvekeys", True)
+if resolvenodes is None:
+resolvenodes = self._repo.ui.configbool("remotenames",
+   "resolvenodes", True)
 for k, vtup in self.potentialentries.iteritems():
-if resolvekeys:
+if resolvenodes:
 self._fetchandcache(k)
 yield (k, [bin(vtup[0])])
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel