Re: [PATCH 1 of 2 resend] templater: add inheritance support to style maps

[Matt Mackall]

On Fri, 2016-08-19 at 23:37 +0900, Yuya Nishihara wrote:
> +elif key == "__base__":
> > +# treat as a pointer to a base class for this style
> > +path = util.normpath(os.path.join(base, val))
> > +bcache, btmap = _readmapfile(path)
> Do we want to make __base__ look for templatepaths?

Yes, that seems very useful.

-- 
Mathematics is the supreme nostalgia of our time.

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

[PATCH] hgweb: add inheritance support to style maps

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1471459227 18000
#  Wed Aug 17 13:40:27 2016 -0500
# Node ID f2bb8352d994be9bb9ca55d49dacba35c996d8cf
# Parent  73ff159923c1f05899c27238409ca398342d9ae0
hgweb: add inheritance support to style maps

We can now specify a base map file:

__base__ = path/to/map/file

That map file will be read and used to populate unset elements of the
current map. Unlike using %include, elements in the inherited class
will be read relative to that path.

This makes it much easier to make custom local tweaks to a style.

diff -r 73ff159923c1 -r f2bb8352d994 mercurial/templater.py
--- a/mercurial/templater.pyMon Aug 01 13:14:13 2016 -0400
+++ b/mercurial/templater.pyWed Aug 17 13:40:27 2016 -0500
@@ -1026,6 +1026,16 @@
 raise error.ParseError(_('unmatched quotes'),
conf.source('', key))
 cache[key] = unquotestring(val)
+elif key == "__base__":
+# treat as a pointer to a base class for this style
+path = util.normpath(os.path.join(base, val))
+bcache, btmap = _readmapfile(path)
+for k in bcache:
+if k not in cache:
+cache[k] = bcache[k]
+for k in btmap:
+if k not in tmap:
+tmap[k] = btmap[k]
 else:
 val = 'default', val
 if ':' in val[1]:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] hgweb: add inheritance support to style maps

[Matt Mackall]

On Thu, 2016-08-18 at 17:48 +0900, Yuya Nishihara wrote:
> On Thu, 18 Aug 2016 11:52:11 +0800, Anton Shestakov wrote:
> > 
> > 18.08.2016, 03:32, "Matt Mackall" <m...@selenic.com>:
> > > 
> > > # HG changeset patch
> > > # User Matt Mackall <m...@selenic.com>
> > > # Date 1471459227 18000
> > > # Wed Aug 17 13:40:27 2016 -0500
> > > # Node ID f2bb8352d994be9bb9ca55d49dacba35c996d8cf
> > > # Parent 73ff159923c1f05899c27238409ca398342d9ae0
> > > hgweb: add inheritance support to style maps
> > > 
> > > We can now specify a base map file:
> > > 
> > > __base__ = path/to/map/file
> > > 
> > > That map file will be read and used to populate unset elements of the
> > > current map. Unlike using %include, elements in the inherited class
> > > will be read relative to that path.
> > > 
> > > This makes it much easier to make custom local tweaks to a style.
> > I like the idea, but I just don't find __base__ =  self-explanatory
> > enough.
> It makes some sense because a mapfile value is |'"'  '"'. But
> I'd rather change %include to behave like __base__.

That'll break anything that has learned from what coal is currently doing.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] hgweb: add inheritance support to style maps

[Matt Mackall]

On Thu, 2016-08-18 at 11:52 +0800, Anton Shestakov wrote:
> 18.08.2016, 03:32, "Matt Mackall" <m...@selenic.com>:
> > 
> > # HG changeset patch
> > # User Matt Mackall <m...@selenic.com>
> > # Date 1471459227 18000
> > # Wed Aug 17 13:40:27 2016 -0500
> > # Node ID f2bb8352d994be9bb9ca55d49dacba35c996d8cf
> > # Parent 73ff159923c1f05899c27238409ca398342d9ae0
> > hgweb: add inheritance support to style maps
> > 
> > We can now specify a base map file:
> > 
> > __base__ = path/to/map/file
> > 
> > That map file will be read and used to populate unset elements of the
> > current map. Unlike using %include, elements in the inherited class
> > will be read relative to that path.
> > 
> > This makes it much easier to make custom local tweaks to a style.
> I like the idea, but I just don't find __base__ =  self-explanatory
> enough.
> 
> Why not something like %extend ? It would look on the same level of
> "special" as %include, which may help understanding what it does at a glance.

%include is/must be implemented in the config file parser. This is implemented
in the templater, where it can apply the specific semantics of the template
value rules (like files vs quoted strings).

-- 
Mathematics is the supreme nostalgia of our time.

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

[PATCH 1 of 2 resend] templater: add inheritance support to style maps

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1471459227 18000
#  Wed Aug 17 13:40:27 2016 -0500
# Node ID 1f402560299be8692c767db1469afb6618adee81
# Parent  b1809f5d7630a3fff0fa715bbd30dba0f07672a8
templater: add inheritance support to style maps

We can now specify a base map file:

__base__ = path/to/map/file

That map file will be read and used to populate unset elements of the
current map. Unlike using %include, elements in the inherited class
will be read relative to that path.

This makes it much easier to make custom local tweaks to a style.

diff -r b1809f5d7630 -r 1f402560299b mercurial/templater.py
--- a/mercurial/templater.pyMon Aug 15 20:39:33 2016 -0700
+++ b/mercurial/templater.pyWed Aug 17 13:40:27 2016 -0500
@@ -1026,6 +1026,16 @@
 raise error.ParseError(_('unmatched quotes'),
conf.source('', key))
 cache[key] = unquotestring(val)
+elif key == "__base__":
+# treat as a pointer to a base class for this style
+path = util.normpath(os.path.join(base, val))
+bcache, btmap = _readmapfile(path)
+for k in bcache:
+if k not in cache:
+cache[k] = bcache[k]
+for k in btmap:
+if k not in tmap:
+tmap[k] = btmap[k]
 else:
 val = 'default', val
 if ':' in val[1]:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] hgweb: add inheritance support to style maps

[Matt Mackall]

On Wed, 2016-08-17 at 15:56 -0400, Augie Fackler wrote:
> On Wed, Aug 17, 2016 at 02:31:45PM -0500, Matt Mackall wrote:
> > 
> > # HG changeset patch
> > # User Matt Mackall <m...@selenic.com>
> > # Date 1471459227 18000
> > #  Wed Aug 17 13:40:27 2016 -0500
> > # Node ID f2bb8352d994be9bb9ca55d49dacba35c996d8cf
> > # Parent  73ff159923c1f05899c27238409ca398342d9ae0
> > hgweb: add inheritance support to style maps
> I like it.
> 
> Can I get a simple test that changes something simple in paper and
> shows that it works?

Derp, I only sent the first patch.

-- 
Mathematics is the supreme nostalgia of our time.

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

[PATCH 2 of 2 resend] coal: use inheritance to derive from paper

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1471459393 18000
#  Wed Aug 17 13:43:13 2016 -0500
# Node ID 0dae6896d5c890e711497775805d8890cf624e1c
# Parent  1f402560299be8692c767db1469afb6618adee81
coal: use inheritance to derive from paper

This illustrates how much simpler this approach is, in particular the
effect of map-relative paths.

diff -r 1f402560299b -r 0dae6896d5c8 mercurial/templates/coal/map
--- a/mercurial/templates/coal/map  Wed Aug 17 13:40:27 2016 -0500
+++ b/mercurial/templates/coal/map  Wed Aug 17 13:43:13 2016 -0500
@@ -1,34 +1,2 @@
-%include paper/map
-
-footer = ../paper/footer.tmpl
-search = ../paper/search.tmpl
-
-changelog = ../paper/shortlog.tmpl
-shortlog = ../paper/shortlog.tmpl
-shortlogentry = ../paper/shortlogentry.tmpl
-graph = ../paper/graph.tmpl
-
-help = ../paper/help.tmpl
-helptopics = ../paper/helptopics.tmpl
-
-diffstatlink = ../paper/diffstat.tmpl
-diffstatnolink = ../paper/diffstat.tmpl
-changelogentry = ../paper/shortlogentry.tmpl
-searchentry = ../paper/shortlogentry.tmpl
-changeset = ../paper/changeset.tmpl
-manifest = ../paper/manifest.tmpl
-
-filerevision = ../paper/filerevision.tmpl
-fileannotate = ../paper/fileannotate.tmpl
-filediff = ../paper/filediff.tmpl
-filecomparison = ../paper/filecomparison.tmpl
-filelog = ../paper/filelog.tmpl
-filelogentry = ../paper/filelogentry.tmpl
-
-tags = ../paper/tags.tmpl
-bookmarks = ../paper/bookmarks.tmpl
-branches = ../paper/branches.tmpl
-
-index = ../paper/index.tmpl
-notfound = ../paper/notfound.tmpl
-error = ../paper/error.tmpl
+__base__ = ../paper/map
+header = header.tmpl
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] templater: add template path to __base__ search

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1472085825 25200
#  Wed Aug 24 17:43:45 2016 -0700
# Node ID 1ec871261bb777e24f21cb180fce199cb49c55ea
# Parent  5f86818c95e5ea59c48dfceca2e286cd11f9a800
templater: add template path to __base__ search

This does a fall-back check for style files or directories that are
in Mercurial's template path for user convenience.

We intentionally don't use this for the built-in coal style because we don't
want the style to mysteriously break if the working directory just
happens to have a file named "paper".

diff -r 5f86818c95e5 -r 1ec871261bb7 mercurial/templater.py
--- a/mercurial/templater.pyWed Aug 17 13:43:13 2016 -0500
+++ b/mercurial/templater.pyWed Aug 24 17:43:45 2016 -0700
@@ -1029,6 +1029,19 @@
 elif key == "__base__":
 # treat as a pointer to a base class for this style
 path = util.normpath(os.path.join(base, val))
+
+# fallback check in template paths
+if not os.path.exists(path):
+for p in templatepaths():
+p2 = util.normpath(os.path.join(p, val))
+if os.path.isfile(p2):
+path = p2
+break
+p3 = util.normpath(os.path.join(p2, "map"))
+if os.path.isfile(p3):
+path = p3
+break
+
 bcache, btmap = _readmapfile(path)
 for k in bcache:
 if k not in cache:
diff -r 5f86818c95e5 -r 1ec871261bb7 tests/test-command-template.t
--- a/tests/test-command-template.t Wed Aug 17 13:43:13 2016 -0500
+++ b/tests/test-command-template.t Wed Aug 24 17:43:45 2016 -0700
@@ -103,6 +103,18 @@
   $ hg log -l1 -T./map-simple
   8
 
+Test template map inheritance
+
+  $ echo "__base__ = map-cmdline.default" > map-simple
+  $ printf 'cset = "changeset: ***{rev}***\\n"\n' >> map-simple
+  $ hg log -l1 -T./map-simple
+  changeset: ***8***
+  tag: tip
+  user:test
+  date:Wed Jan 01 10:01:00 2020 +
+  summary: third
+  
+
 Template should precede style option
 
   $ hg log -l1 --style default -T '{rev}\n'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 8 of 8 v2] help: mark boolean flags with a ^ and explain that they can be negated (RFC)

[Matt Mackall]

On Wed, 2016-08-31 at 13:10 -0400, Augie Fackler wrote:
> On Wed, Aug 31, 2016 at 12:13 PM, Matt Mackall <m...@selenic.com> wrote:
> > 
> > On Tue, 2016-08-30 at 16:16 -0400, Augie Fackler wrote:
> > > 
> > > # HG changeset patch
> > > # User Augie Fackler <au...@google.com>
> > > # Date 147258 14400
> > > #  Tue Aug 30 15:14:04 2016 -0400
> > > # Node ID 5efc13a760938ff5fd8e4553dd8e06d06b98025b
> > > # Parent  fd68fb86c29873eb32c4a2bd28f7ac0abe3dc172
> > > help: mark boolean flags with a ^ and explain that they can be negated
> > > (RFC)
> > 
> > > 
> > >  options ([+] can be repeated, flags marked ^ can be negated with --no-):
> > The format here is a bit inconsistent. Perhaps:
> > 
> >   options ([+] can be repeated, [?] are flags):
> > 
> > I think actually sticking ^ on the option name itself is a little bizarre
> > and
> > might lead to some minor confusion.
> > 
> > Also, we should probably figure out a way to have aliases for some of these
> > options so we can fully normalize the scheme. Consider:
> > 
> > > 
> > > +   -y --noninteractive^   do not prompt, automatically pick the first
> > > choice
> > Having --no-noninteractive seems really sad. We could make --noninteractive
> > hidden and then advertise --no-interactive as the long version.
> > 
> > Also, I don't think --no-no-backup is a good idea. --backup should be its
> > negation.
> These cases are a bit problematic, because we don't really have a way
> to specify default-true flags.

I was thinking --no-backup would be detected as an inverse. So the parser would
synthesize a --backup option and if it was used bare, opts["no_backup"] would be
set to False rather than None. Maybe that's too convoluted though.

>  Would it be good enough to blacklist
> anything that starts with no- and noninteractive for now?

Yep. Though it's a bit of a shame for fancyopts to acquire such knowledge.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] bundle2: handleoutput i18n

[Matt Mackall]

On Wed, 2016-08-31 at 22:57 +0900, Akihiko Odaki wrote:
> On 2016-08-30 13:19, Matt Mackall wrote:
> > 
> > On Tue, 2016-08-30 at 11:10 +0900, Akihiko Odaki wrote:
> > > 
> > > Hi,
> > > 
> > > Thanl you for reviewing my patch.

Since we're cutting a release today, we're going to drop an edited version of
this into the stable branch. Thanks!

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH rfc] manifest: write a more efficient version of lazymanifest, in pure python

[Matt Mackall]

On Fri, 2016-08-26 at 16:57 -0700, Sean Farley wrote:
> Matt Mackall <m...@selenic.com> writes:
> 
> > 
> > On Wed, 2016-08-24 at 23:55 -0400, Augie Fackler wrote:
> > > 
> > > > 
> > > > 
> > > > On Aug 20, 2016, at 5:02 PM, Maciej Fijalkowski <fij...@gmail.com>
> > > > wrote:
> > > > 
> > > > # HG changeset patch
> > > > # User Maciej Fijalkowski <fij...@gmail.com>
> > > > # Date 1471726818 -7200
> > > > #  Sat Aug 20 23:00:18 2016 +0200
> > > > # Node ID 21b2401d468d6b24c1658468e4fc5ce8744f925b
> > > > # Parent  300f14ea21432face8d7e6cdcf92ba9d2f1f92dc
> > > > manifest: write a more efficient version of lazymanifest, in pure python
> > > > 
> > > > Questions outsdanding:
> > > > * who calls filtercopy? noone in tests at the very least
> > > manifest.py line 287 or thereabouts: it’s used for matches() on a
> > > manifest.
> > > test-status-rev.t will exercise that codepath if that helps.
> > > 
> > > > 
> > > > 
> > > > * are the performance tradeoffs ok here, notably __delitem__?
> > > Probably. It looks very similar to the C version. Deleting a ton of
> > > entries
> > > from a large manifest is probably still tragic, since it’ll be a lot of
> > > copies, but for a first pass this is already so much better than the naive
> > > version that was there...
> > > 
> > > > 
> > > > 
> > > > * should we use mmap instead of reading stuff from a file?
> > > This I can’t answer. Maybe?
> > > 
> > > > 
> > > > 
> > > > * current version does not support 21 or 22 long hashes, why are they
> > > > necessary?
> > > There are a handful of (weird) places that do something like poke a “+” on
> > > the
> > > end of a hash in the manifest to mark it as dirty, but that is never saved
> > > to
> > > disk.
> > FWIW, we could probably replace the "+" hack with an "C"*40 hack. The SHA1
> > space
> > is big enough that we can punch some other small holes in it in addition to
> > the
> > null hash.
> I thought Yuya was working on adding "F"*40 (unless I missed something
> special about "C"?)?

It's just a number with a 2^-160 probability of collision with a real hash.
... was chosen as a pseudo-hash for the working copy pseudo-changeset to
contrast with the all-zeros representation of nullid. C... is simply a
(confusing) mnemonic for "changed" since M isn't available.

Having the pseudo-hashes for the file-level and changeset-level be the same is
slightly risky since we have nothing in Python that prevents us from ever
comparing these different types. But it has the upside that they have similar
interpretations.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] journal: rename on disk files to 'namejournal'

[Matt Mackall]

On Sat, 2016-08-27 at 22:47 +, Gábor STEFANIK wrote:
> Please forgive my ignorance, but do we even have BC guarantees for extensions?

Yes.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] update: do not remove cwd

[Matt Mackall]

On Mon, 2016-08-29 at 11:50 -0700, Stanislau Hlebik wrote:
> # HG changeset patch
> # User Stanislau Hlebik 
> # Date 1472496038 25200
> #  Mon Aug 29 11:40:38 2016 -0700
> # Node ID e1962781ce84040746ef79c0084b8fd70cfcd4b4
> # Parent  318e2b600b80e4ed3c6f37df46ec7544f60d4c0b
> update: do not remove cwd
> 
> During update directories are deleted as soon as they have no entries.
> But current working directory shouldn't be deleted because it
> causes problems for users after hg finishes.

It is a perfectly valid state that POSIX allows. So we shouldn't make those
problems our problems.

>  Also it makes complex commands
> like 'hg split' fail.

Those failures are also arguably bugs in their own right.

But this approach introduces new complexities. For instance, what happens if the
current directory gets replaced by a symlink? Whether that works depends on
where you run the command. And how does the not-deleted directory get cleaned up
so as not to interfere with future operations?

If we wanted to disallow this, we'd ideally abort early so the user could run
the operation in a sane location. But that's not generally easy to discover. And
aborting later is likely to make a mess.

(Alternate idea: rename the current directory to .oh-no-you-ran-an-hg-command-
that-deleted-your-current-directory-please-clean-up-your-mess-kthxbye.)

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH V2] dirstate: rebuild should update dirstate properly

[Matt Mackall]

On Tue, 2016-08-30 at 15:17 -0700, Mateusz Kwapich wrote:
> # HG changeset patch
> # User Mateusz Kwapich 
> # Date 1472595388 25200
> #  Tue Aug 30 15:16:28 2016 -0700
> # Node ID aff2b9911d78a3d427e3ba18a565e76215971948
> # Parent  12f8bef59bfa2739d0c5d8425ab494fd2fe38a81
> dirstate: rebuild should update dirstate properly

Is this appropriate for stable?

> Updating dirstate by simply adding and dropping files from self._map doesn't
> keep the other maps updated (think: _dirs, _copymap, _foldmap, _nonormalset)
> thus introducing cache inconsistency.
> 
> This is also affecting the debugstate tests since now we don't even try to set
> correct mode and mtime for the files because they are marked dirty anyway and
> will be checked during next status call.
> 
> diff --git a/mercurial/dirstate.py b/mercurial/dirstate.py
> --- a/mercurial/dirstate.py
> +++ b/mercurial/dirstate.py
> @@ -680,21 +680,15 @@ class dirstate(object):
>  self.clear()
>  self._lastnormaltime = lastnormaltime
>  
> -for f in changedfiles:
> -mode = 0o666
> -if f in allfiles and 'x' in allfiles.flags(f):
> -mode = 0o777
> -
> -if f in allfiles:
> -self._map[f] = dirstatetuple('n', mode, -1, 0)
> -else:
> -self._map.pop(f, None)
> -if f in self._nonnormalset:
> -self._nonnormalset.remove(f)
> -
>  if self._origpl is None:
>  self._origpl = self._pl
>  self._pl = (parent, nullid)
> +for f in changedfiles:
> +if f in allfiles:
> +self.normallookup(f)
> +else:
> +self.drop(f)
> +
>  self._dirty = True
>  
>  def write(self, tr):
> diff --git a/tests/test-rebuildstate.t b/tests/test-rebuildstate.t
> --- a/tests/test-rebuildstate.t
> +++ b/tests/test-rebuildstate.t
> @@ -48,8 +48,8 @@ basic test for hg debugrebuildstate
>  state dump after
>  
>    $ hg debugstate --nodates | sort
> -  n 644 -1 set bar
> -  n 644 -1 set foo
> +  n   0 -1 unset   bar
> +  n   0 -1 unset   foo
>  
>    $ hg debugadddrop --normal-lookup file1 file2
>    $ hg debugadddrop --drop bar
> @@ -57,7 +57,7 @@ state dump after
>    $ hg debugstate --nodates
>    n   0 -1 unset   file1
>    n   0 -1 unset   file2
> -  n 644 -1 set foo
> +  n   0 -1 unset   foo
>    $ hg debugrebuildstate
>  
>  status
> @@ -115,7 +115,7 @@ dirstate
>    $ hg debugrebuilddirstate --minimal
>    $ hg debugdirstate --nodates
>    r   0  0 * bar (glob)
> -  n 644 -1 * foo (glob)
> +  n   0 -1 * foo (glob)
>    a   0 -1 * qux (glob)
>    $ hg status -A
>    A qux
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] bundle2: handleoutput i18n

[Matt Mackall]

On Tue, 2016-08-30 at 11:10 +0900, Akihiko Odaki wrote:
> Hi,
> 
> Thanl you for reviewing my patch.
> 
> On 2016-08-30 09:38, Matt Mackall wrote:
>  > On Sun, 2016-08-28 at 10:57 +0900, Akihiko Odaki wrote:
>  >> # HG changeset patch
>  >> # User Akihiko Odaki <akihiko.odaki...@stu.hosei.ac.jp>
>  >> # Date 1472348629 -32400
>  >> #  Sun Aug 28 10:43:49 2016 +0900
>  >> # Node ID 3e9c35285720b3eecbda43d3d60e483d63ba7ae4
>  >> # Parent  4fca69e3d51cc45f331a74caa6e923523ebf7f02
>  >> bundle2: handleoutput i18n
>  >
>  > This would be easier to read as "bundle2: localize handleoutput 
> remote prompts"
> 
> I understand.
> 
>  >
>  >> diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
>  >> --- a/mercurial/bundle2.py
>  >> +++ b/mercurial/bundle2.py
>  >> @@ -1467,7 +1467,7 @@ def handlecheckheads(op, inpart):
>  >>  def handleoutput(op, inpart):
>  >>  """forward output captured on the server to the client"""
>  >>  for line in inpart.read().splitlines():
>  >> -op.ui.status(('remote: %s\n' % line))
>  >
>  > You'll note there is an extra level of useless parentheses here. They 
> actually
>  > serve a purpose: they stop check-code.py from complaining about not 
> using _().
>  >
>  > So someone didn't put _() there on purpose. Whenever you see something
>  > apparently pointless that was also clearly done on purpose, you need 
> to figure
>  > out why it was done before you take it out: you might be breaking 
> something that
>  > isn't obvious.
> 
> I thought it should use _() because other codes do so. Here is `grep -r 
> 'remote: ' mercurial`.

Yes, that does appear right. But did you also check the history of the file
you're changing to see if there was a reason that someone used () to silence a
warning rather than just using _() correctly?

Again: someone went to extra effort to do it "wrong". Before we can "fix" it, we
should try to figure out why.[1]

Also, if you figure out why, don't explain it to me, explain it to your commit
message editor.

[1] This principle is sometimes known as Chesterton's Fence:
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH STABLE] bundle2: localize "remote: "

[Matt Mackall]

On Tue, 2016-08-30 at 17:49 -0700, Gregory Szorc wrote:

> However, I'm going to posit that _() not being used was accidental. We
> translate "remote: " everywhere else. This code is running locally (not on
> the server). So I don't see why we wouldn't tranhslate.

I agree it's almost certainly wrong.

But the thing I'm getting at is:

- we've had rules forever to make sure all write/status messages get translated
- so it's weird when one isn't
- and extra weird when an obvious one like this has willfully defeated the rule
- such weirdness should trigger a higher level of investigation and rationale 

When we fix things that are obviously wrong, we always risk breaking things that
are actually subtly right. A really good warning sign that we're about to do
that is when we find something that's obviously wrong.. but also inexplicable.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] evolution: make troubles appear in default log (issue4686)

[Matt Mackall]

On Wed, 2016-09-07 at 15:23 -0400, Augie Fackler wrote:
> On Fri, Sep 02, 2016 at 10:26:22AM -0500, Kevin Bullock wrote:
> > 
> > > 
> > > On Sep 2, 2016, at 04:38, liscju  wrote:
> > > 
> > > # HG changeset patch
> > > # User liscju 
> > > # Date 1472809041 -7200
> > > #  Fri Sep 02 11:37:21 2016 +0200
> > > # Node ID 463b164126a0db3f7147787ace34f74deeccc03f
> > > # Parent  f148bfa40489269be2e48046734f81065129847a
> > > evolution: make troubles appear in default log (issue4686)
> > > 
> > > This patch is request for comment, it does not update failing
> > > test due to new information about troubles, it adds one test
> > > to show how troubles looks like in default log.
> > 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 a no-no.
> There's caselaw for adding new lines to the -Tdefault output
> (bookmarks come to mind), so I think we can probably do that?

Bookmarks and branches did indeed get output added to default log. But no user
would see that output until they started using those things (one of the reasons
the "default" branch is invisible). So fragile tooling that couldn't handle them
appearing wouldn't break simply from upgrading. 

There are two key points to this pattern:

- no behavior change for repos not using a feature
- output change is introduced WITH the feature

This second is essential to ensure that there's no timeframe where users could
start coding production scripts against the feature and then get broken simply
by upgrading. Note that it IS ok if using a new feature breaks something (that's
unavoidable!) but it's NOT ok if simply upgrading does.

So this boat has already sailed for "troubles", because we've had them for a
while.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH 2 of 5] extdata: add revset support for extdata

[Matt Mackall]

On Sat, 2016-09-24 at 00:22 +0200, Pierre-Yves David wrote:
> 
> On 09/23/2016 07:34 PM, Matt Mackall wrote:
> > 
> > On Fri, 2016-09-23 at 19:49 +0900, FUJIWARA Katsunori wrote:
> > > 
> > > At Thu, 22 Sep 2016 13:21:36 -0500,
> > > Matt Mackall wrote:
> > > > 
> > > > 
> > > > 
> > > > # HG changeset patch
> > > > # User Matt Mackall <m...@selenic.com>
> > > > # Date 1474293900 18000
> > > > #  Mon Sep 19 09:05:00 2016 -0500
> > > > # Node ID 9c8847df32a0c5045e60aded2e03a9c97507f909
> > > > # Parent  19bf2776dfe39befdc479253e1e7d030b41c08f9
> > > > extdata: add revset support for extdata
> > > > 
> > > > This inserts extdata into the revset function support. Planned
> > > > extensions of extdata support arguments, so this is the most
> > > > appropriate place for it.
> > > > 
> > > > Unfortunately, the registrar framework is not a good fit here. First,
> > > > setting an appropriate load point is still an unsolved problem (we
> > > > want the code to live in revset.py, but that module may never be
> > > > loaded).
> > > > Second, registered methods become global and the data sources are likely
> > > > to
> > > > be
> > > > repo-specific. This won't work well in a context like hgwebdir.
> > > Is there any reason not to define extdata() revset predicate (or
> > > template function), which requires external data source name like as
> > > extdata('filedata') ? (for convenience ?)
> > It's mostly convenience. But I also plan to add support for arguments.
> I think I really like foozy idea about using a generic 'extdata("key")' 
> predicate. That will probably be okay for many case and prevent 
> unexpected collision with other revsets. If needed, the user can easily 
> define a revset alias for the sources in needs easy access to. As 
> configuration of the source is needed anyway, this does seems like a 
> bearable burden.
> 
> If I remember correctly, it does not seems to have limitation in the 
> current implementation of revset that would prevent use to do 
> 'extdata("key", arg1, arg2)'

You get to implement this version, because I think it's an awful idea.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH 1 of 5] extdata: add extdatasource reader

[Matt Mackall]

On Thu, 2016-10-06 at 07:52 +0200, Mathias De Maré wrote:
> On Thu, Sep 22, 2016 at 8:21 PM, Matt Mackall <m...@selenic.com> wrote:
> 
> > 
> > # HG changeset patch
> > # User Matt Mackall <m...@selenic.com>
> > # Date 1473794045 18000
> > #  Tue Sep 13 14:14:05 2016 -0500
> > # Node ID 19bf2776dfe39befdc479253e1e7d030b41c08f9
> > # Parent  5271ae66615207f39cc41d78f4541bc6f8ca6ff6
> > extdata: add extdatasource reader
> > 
> > This adds basic support for extdata, a way to add external data
> > sources for revsets and templates. An extdata data source is simply a
> > list of lines of the form:
> > 
> > []\n
> > 
> > An extdata source is configured thusly:
> > 
> > [extdata]
> > name = 
> > 
> > urls of the form shell: are launch shell commands to generate data.
> > 
> This looks great!
> We've been using a small extension to load an external file with tags into
> one of our repositories. Do you think that could fit here as well?
> 
> Something like this would be nice:
> [extdata]
> name = 
> name.type = tags

Do you actually need it to be a 'tag' or is it good enough that it be a named
identifier in the current union of namespaces?

Extdata as presently designed doesn't add new names for nodes to the namespaces.
But having a way to import an arbitrary name mapping would indeed be handy. For
instance, for having a mapping to other version control system identifiers.

> name.checkrev =  loading the tags>

Can you explain more about checkrev?

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH 1 of 5] extdata: add extdatasource reader

[Matt Mackall]

On Thu, 2016-09-22 at 18:20 -0500, Kevin Bullock wrote:
> > 
> > On Sep 22, 2016, at 13:21, Matt Mackall <m...@selenic.com> wrote:
> > 
> > # HG changeset patch
> > # User Matt Mackall <m...@selenic.com>
> > # Date 1473794045 18000
> > #  Tue Sep 13 14:14:05 2016 -0500
> > # Node ID 19bf2776dfe39befdc479253e1e7d030b41c08f9
> > # Parent  5271ae66615207f39cc41d78f4541bc6f8ca6ff6
> > extdata: add extdatasource reader
> > 
> > This adds basic support for extdata, a way to add external data
> > sources for revsets and templates. An extdata data source is simply a
> > list of lines of the form:
> > 
> > []\n
> > 
> > An extdata source is configured thusly:
> > 
> > [extdata]
> > name = 
> > 
> > urls of the form shell: are launch shell commands to generate data.
> > 
> > diff -r 5271ae666152 -r 19bf2776dfe3 mercurial/scmutil.py
> > --- a/mercurial/scmutil.py  Wed Sep 21 17:05:27 2016 -0400
> > +++ b/mercurial/scmutil.py  Tue Sep 13 14:14:05 2016 -0500
> > @@ -29,6 +29,7 @@
> > phases,
> > revset,
> > similar,
> > +url,
> > util,
> > )
> > 
> > @@ -1418,3 +1419,66 @@
> > return
> > 
> > self._queue.put(fh, block=True, timeout=None)
> > +
> > +def extdatasources(repo):
> > +sources = set()
> > +for k, v in repo.ui.configitems("extdata"):
> > +sources.add(k)
> > +return sources
> > +
> > +def extdatasource(repo, source):
> > +"""gather a map of rev -> value dict from the specified source
> > +
> > +A source spec is treated as a URL, with a special case shell: type
> > +for parsing the output from a shell command.
> > +
> > +The data is parsed as a series of newline-separated records where
> > +each record is a revision specifier optionally followed by a space
> > +and a freeform string value. If the revision is known locally, it
> > +is converted to a rev, otherwise the record is skipped.
> > +
> > +Note that both key and value are treated as UTF-8 and converted to
> > +the local encoding. This allows uniformity between local and
> > +remote data sources.
> That's a bit unfortunate. If we're expecting them to be read as UTF-8, can't
> we just keep them in UTF-8 all the way thru?

We always work internally in the local encoding. Sane local encodings include:
utf-8. We've normally got two strategies: files owned by users and stored in
local encoding (hgrc) and files owned by Mercurial and stored in utf-8
(bookmarks). So this note is to point out that this is different from the usual
case.. because URLs might (or might not) be remote, shared resources that need
to be in utf-8 for portability.

> > 
> > +"""
> > +
> > +spec = repo.ui.config("extdata", source)
> > +if not spec:
> > +raise util.Abourt(_("unknown extdata source '%s'") % source)
> Typo here. I suppose there's no great way to test against this.

Indeed, both of the current callers prevent this code from being reached.

> > 
> > +
> > +try:
> > +# prepare for future expansion
> > +expand = spec % ()
> > +except TypeError:
> > +raise error.Abort(_("extdata doesn't support parameters yet"),
> > +  hint=_("use double % for escaping"))
> > +
> > +data = {}
> > +if spec.startswith("shell:"):
> > +# external commands should be run relative to the repo root
> > +cmd = spec[6:]
> > +cwd = os.getcwd()
> > +os.chdir(repo.root)
> > +try:
> > +src = util.popen(cmd)
> Erm, don't we want to use util.popen2 or one of the other variants that use
> subprocess instead?

The universal advantages of subprocess are overstated. For the simple task of
reading stdout from a subprocess, util.popen is perfectly suited. If it wasn't..
we'd fix util.popen.

> ...and maybe handle ENOENT gracefully?

We can't, because cmd is an arbitrary shell expression.

> pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
> Kevin R. Bullock
-- 
Mathematics is the supreme nostalgia of our time.

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

[PATCH 2 of 5] extdata: add revset support for extdata

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1474293900 18000
#  Mon Sep 19 09:05:00 2016 -0500
# Node ID 9c8847df32a0c5045e60aded2e03a9c97507f909
# Parent  19bf2776dfe39befdc479253e1e7d030b41c08f9
extdata: add revset support for extdata

This inserts extdata into the revset function support. Planned
extensions of extdata support arguments, so this is the most
appropriate place for it.

Unfortunately, the registrar framework is not a good fit here. First,
setting an appropriate load point is still an unsolved problem (we
want the code to live in revset.py, but that module may never be loaded).
Second, registered methods become global and the data sources are likely to be
repo-specific. This won't work well in a context like hgwebdir.

diff -r 19bf2776dfe3 -r 9c8847df32a0 mercurial/revset.py
--- a/mercurial/revset.py   Tue Sep 13 14:14:05 2016 -0500
+++ b/mercurial/revset.py   Mon Sep 19 09:05:00 2016 -0500
@@ -432,6 +432,14 @@
 return fn(repo, subset, b, order)
 return fn(repo, subset, b)
 
+# avoid import cycle
+from . import scmutil
+
+# check external data sources (can't override built-ins)
+if f in scmutil.extdatasources(repo):
+extdata = scmutil.extdatasource(repo, f)
+return baseset([r for r in subset if r in extdata])
+
 keep = lambda fn: getattr(fn, '__doc__', None) is not None
 
 syms = [s for (s, fn) in symbols.items() if keep(fn)]
diff -r 19bf2776dfe3 -r 9c8847df32a0 tests/test-revset.t
--- a/tests/test-revset.t   Tue Sep 13 14:14:05 2016 -0500
+++ b/tests/test-revset.t   Mon Sep 19 09:05:00 2016 -0500
@@ -3540,6 +3540,31 @@
   1
   3
 
+test extdata revset support
+
+  $ echo "[extdata]" >> .hg/hgrc
+  $ echo "filedata = file:extdata.txt" >> .hg/hgrc
+  $ echo "shelldata = shell:cat extdata.txt | grep 2" >> .hg/hgrc
+  $ echo "2" > extdata.txt
+  $ echo "3" >> extdata.txt
+
+  $ hg log -qr "filedata()"
+  2:842c8a27ccf2
+  3:b7e1eaa35f23
+  $ hg log -qr "shelldata()"
+  2:842c8a27ccf2
+
+we don't fix up relative file URLs, but we do run shell commands in repo root
+
+  $ mkdir sub
+  $ cd sub
+  $ hg log -qr "filedata()"
+  abort: error: No such file or directory
+  [255]
+  $ hg log -qr "shelldata()"
+  2:842c8a27ccf2
+  $ cd ..
+
 test error message of bad revset
   $ hg log -r 'foo\\'
   hg: parse error at 3: syntax error in revset 'foo\\'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 5 of 5] extdata: pass contexts to hgweb templates

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1474310889 18000
#  Mon Sep 19 13:48:09 2016 -0500
# Node ID e6e68432abcbeec0a74478f03762b0b3192c09b5
# Parent  6db1b2e7d19ed317404c1275db46780d40ececb8
extdata: pass contexts to hgweb templates

This makes hgweb more in line with the command line templater, and
gives access to the extdata sources.

diff -r 6db1b2e7d19e -r e6e68432abcb mercurial/hgweb/webutil.py
--- a/mercurial/hgweb/webutil.pyMon Sep 19 09:16:00 2016 -0500
+++ b/mercurial/hgweb/webutil.pyMon Sep 19 13:48:09 2016 -0500
@@ -325,6 +325,7 @@
 'bookmarks': nodebookmarksdict(repo, node),
 'parent': lambda **x: parents(ctx),
 'child': lambda **x: children(ctx),
+'ctx': ctx
 }
 
 def changelistentry(web, ctx, tmpl):
diff -r 6db1b2e7d19e -r e6e68432abcb tests/test-hgweb-raw.t
--- a/tests/test-hgweb-raw.tMon Sep 19 09:16:00 2016 -0500
+++ b/tests/test-hgweb-raw.tMon Sep 19 13:48:09 2016 -0500
@@ -55,4 +55,35 @@
   $ cat access.log error.log
   127.0.0.1 - - [*] "GET 
/?f=bf0ff59095c9;file=sub/some%20text%25.txt;style=raw HTTP/1.1" 200 - (glob)
 
-  $ cd ..
+Test extdata support in hgweb
+
+  $ mkdir mystyle
+  $ echo "__base__ = raw" > mystyle/map
+  $ echo 'changelogentry = changelog.tmpl' >> mystyle/map
+  $ echo '{node|short} {if(push, "(pushed by {push})")}' > 
mystyle/changelog.tmpl
+
+  $ echo "[extdata]" >> .hg/hgrc
+  $ echo "push = pushlog.txt" >> .hg/hgrc
+  $ echo "0 bob" > pushlog.txt
+
+  $ rm access.log error.log
+  $ hg serve -p $HGPORT -A access.log -E error.log -d --pid-file=hg.pid \
+  > --config web.guessmime=True -t mystyle
+
+  $ cat hg.pid >> $DAEMON_PIDS
+  $ (get-with-headers.py localhost:$HGPORT 'changelog' content-type 
content-length content-disposition) >getoutput.txt
+  $ killdaemons.py hg.pid
+
+  $ cat getoutput.txt
+  200 Script output follows
+  content-type: text/plain; charset=ascii
+  
+  
+  # HG changelog
+  # Node ID bf0ff59095c91b192667cfe903dcdba4aced4833
+  
+  bf0ff59095c9 (pushed by bob)
+  
+  $ cat access.log error.log
+  127.0.0.1 - - [*] "GET /changelog HTTP/1.1" 200 - (glob)
+
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 5] extdata: add extdatasource reader

[Matt Mackall]

# HG changeset patch
# User Matt Mackall <m...@selenic.com>
# Date 1473794045 18000
#  Tue Sep 13 14:14:05 2016 -0500
# Node ID 19bf2776dfe39befdc479253e1e7d030b41c08f9
# Parent  5271ae66615207f39cc41d78f4541bc6f8ca6ff6
extdata: add extdatasource reader

This adds basic support for extdata, a way to add external data
sources for revsets and templates. An extdata data source is simply a
list of lines of the form:

[]\n

An extdata source is configured thusly:

[extdata]
name = 

urls of the form shell: are launch shell commands to generate data.

diff -r 5271ae666152 -r 19bf2776dfe3 mercurial/scmutil.py
--- a/mercurial/scmutil.py  Wed Sep 21 17:05:27 2016 -0400
+++ b/mercurial/scmutil.py  Tue Sep 13 14:14:05 2016 -0500
@@ -29,6 +29,7 @@
 phases,
 revset,
 similar,
+url,
 util,
 )
 
@@ -1418,3 +1419,66 @@
 return
 
 self._queue.put(fh, block=True, timeout=None)
+
+def extdatasources(repo):
+sources = set()
+for k, v in repo.ui.configitems("extdata"):
+sources.add(k)
+return sources
+
+def extdatasource(repo, source):
+"""gather a map of rev -> value dict from the specified source
+
+A source spec is treated as a URL, with a special case shell: type
+for parsing the output from a shell command.
+
+The data is parsed as a series of newline-separated records where
+each record is a revision specifier optionally followed by a space
+and a freeform string value. If the revision is known locally, it
+is converted to a rev, otherwise the record is skipped.
+
+Note that both key and value are treated as UTF-8 and converted to
+the local encoding. This allows uniformity between local and
+remote data sources.
+"""
+
+spec = repo.ui.config("extdata", source)
+if not spec:
+raise util.Abourt(_("unknown extdata source '%s'") % source)
+
+try:
+# prepare for future expansion
+expand = spec % ()
+except TypeError:
+raise error.Abort(_("extdata doesn't support parameters yet"),
+  hint=_("use double % for escaping"))
+
+data = {}
+if spec.startswith("shell:"):
+# external commands should be run relative to the repo root
+cmd = spec[6:]
+cwd = os.getcwd()
+os.chdir(repo.root)
+try:
+src = util.popen(cmd)
+finally:
+os.chdir(cwd)
+else:
+# treat as a URL or file
+src = url.open(repo.ui, spec)
+
+try:
+for l in src.readlines():
+if " " in l:
+k, v = l.strip().split(" ", 1)
+else:
+k, v = l.strip(), ""
+
+k = encoding.tolocal(k)
+if k in repo:
+# we ignore data for nodes that don't exist locally
+data[repo[k].rev()] = encoding.tolocal(v)
+finally:
+src.close()
+
+return data
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH rfc] manifest: write a more efficient version of lazymanifest, in pure python

[Matt Mackall]

On Fri, 2016-08-26 at 16:57 -0700, Sean Farley wrote:
> Matt Mackall <m...@selenic.com> writes:
> 
> > 
> > On Wed, 2016-08-24 at 23:55 -0400, Augie Fackler wrote:
> > > 
> > > > 
> > > > 
> > > > On Aug 20, 2016, at 5:02 PM, Maciej Fijalkowski <fij...@gmail.com>
> > > > wrote:
> > > > 
> > > > # HG changeset patch
> > > > # User Maciej Fijalkowski <fij...@gmail.com>
> > > > # Date 1471726818 -7200
> > > > #  Sat Aug 20 23:00:18 2016 +0200
> > > > # Node ID 21b2401d468d6b24c1658468e4fc5ce8744f925b
> > > > # Parent  300f14ea21432face8d7e6cdcf92ba9d2f1f92dc
> > > > manifest: write a more efficient version of lazymanifest, in pure python
> > > > 
> > > > Questions outsdanding:
> > > > * who calls filtercopy? noone in tests at the very least
> > > manifest.py line 287 or thereabouts: it’s used for matches() on a
> > > manifest.
> > > test-status-rev.t will exercise that codepath if that helps.
> > > 
> > > > 
> > > > 
> > > > * are the performance tradeoffs ok here, notably __delitem__?
> > > Probably. It looks very similar to the C version. Deleting a ton of
> > > entries
> > > from a large manifest is probably still tragic, since it’ll be a lot of
> > > copies, but for a first pass this is already so much better than the naive
> > > version that was there...
> > > 
> > > > 
> > > > 
> > > > * should we use mmap instead of reading stuff from a file?
> > > This I can’t answer. Maybe?
> > > 
> > > > 
> > > > 
> > > > * current version does not support 21 or 22 long hashes, why are they
> > > > necessary?
> > > There are a handful of (weird) places that do something like poke a “+” on
> > > the
> > > end of a hash in the manifest to mark it as dirty, but that is never saved
> > > to
> > > disk.
> > FWIW, we could probably replace the "+" hack with an "C"*40 hack. The SHA1
> > space
> > is big enough that we can punch some other small holes in it in addition to
> > the
> > null hash.
> I thought Yuya was working on adding "F"*40 (unless I missed something
> special about "C"?)?

It's just a number with a 2^-160 probability of collision with a real hash.
... was chosen as a pseudo-hash for the working copy pseudo-changeset to
contrast with the all-zeros representation of nullid. C... is simply a
(confusing) mnemonic for "changed" since M isn't available.

Having the pseudo-hashes for the file-level and changeset-level be the same is
slightly risky since we have nothing in Python that prevents us from ever
comparing these different types. But it has the upside that they have similar
interpretations.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH] templater: add template path to __base__ search

[Matt Mackall]

On Fri, 2016-08-26 at 11:23 +0200, Pierre-Yves David wrote:
> 
> On 08/25/2016 02:48 AM, Matt Mackall wrote:
> > 
> > # HG changeset patch
> > # User Matt Mackall <m...@selenic.com>
> > # Date 1472085825 25200
> > #  Wed Aug 24 17:43:45 2016 -0700
> > # Node ID 1ec871261bb777e24f21cb180fce199cb49c55ea
> > # Parent  5f86818c95e5ea59c48dfceca2e286cd11f9a800
> > templater: add template path to __base__ search
> > 
> > This does a fall-back check for style files or directories that are
> > in Mercurial's template path for user convenience.
> So this seems to mean we are looking for __base__ the same way we search 
> for style. This seems very sensible.
> 
> > 
> > We intentionally don't use this for the built-in coal style because we don't
> > want the style to mysteriously break if the working directory just
> > happens to have a file named "paper".
> I'm a bit more confused here. First, I would imagine our search priority 
> would help two style next to each other be able to to work together. 
> Second, does this means the working directory is in the template search 
> path? If so how is it not an issue already?

> The new feature is definitly neat and shiny, but if -we- cannot even use 
> it for our most common template this looks like an hatching disaster.

Scenario I'm slightly worried about:

- someone has a working hgweb setup with coal, has never heard of "paper"
- a file named "paper" gets added to hgweb working directory (improbable)
- coal theme mysteriously stops working due to action at a distance

Scenario I'm not worried about:

- user creates a new style that derives from paper
- user now has knowledge of how templater works and the significance of "paper"
- a file named "paper" gets added to hgweb working directory
- system breaks, but it's much less mysterious

The first scenario is unlikely, but we might as well avoid it.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH 2 of 5] extdata: add revset support for extdata

[Matt Mackall]

On Tue, 2016-09-27 at 14:41 +0200, Pierre-Yves David wrote:
> 
> On 09/25/2016 12:43 AM, Matt Mackall wrote:
> > 
> > On Sat, 2016-09-24 at 00:22 +0200, Pierre-Yves David wrote:
> > > 
> > > 
> > > On 09/23/2016 07:34 PM, Matt Mackall wrote:
> > > > 
> > > > 
> > > > On Fri, 2016-09-23 at 19:49 +0900, FUJIWARA Katsunori wrote:
> > > > > 
> > > > > 
> > > > > At Thu, 22 Sep 2016 13:21:36 -0500,
> > > > > Matt Mackall wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > # HG changeset patch
> > > > > > # User Matt Mackall <m...@selenic.com>
> > > > > > # Date 1474293900 18000
> > > > > > #  Mon Sep 19 09:05:00 2016 -0500
> > > > > > # Node ID 9c8847df32a0c5045e60aded2e03a9c97507f909
> > > > > > # Parent  19bf2776dfe39befdc479253e1e7d030b41c08f9
> > > > > > extdata: add revset support for extdata
> > > > > > 
> > > > > > This inserts extdata into the revset function support. Planned
> > > > > > extensions of extdata support arguments, so this is the most
> > > > > > appropriate place for it.
> > > > > > 
> > > > > > Unfortunately, the registrar framework is not a good fit here.
> > > > > > First,
> > > > > > setting an appropriate load point is still an unsolved problem (we
> > > > > > want the code to live in revset.py, but that module may never be
> > > > > > loaded).
> > > > > > Second, registered methods become global and the data sources are
> > > > > > likely
> > > > > > to
> > > > > > be
> > > > > > repo-specific. This won't work well in a context like hgwebdir.
> > > > > Is there any reason not to define extdata() revset predicate (or
> > > > > template function), which requires external data source name like as
> > > > > extdata('filedata') ? (for convenience ?)
> > > > It's mostly convenience. But I also plan to add support for arguments.
> > > I think I really like foozy idea about using a generic 'extdata("key")'
> > > predicate. That will probably be okay for many case and prevent
> > > unexpected collision with other revsets. If needed, the user can easily
> > > define a revset alias for the sources in needs easy access to. As
> > > configuration of the source is needed anyway, this does seems like a
> > > bearable burden.
> > > 
> > > If I remember correctly, it does not seems to have limitation in the
> > > current implementation of revset that would prevent use to do
> > > 'extdata("key", arg1, arg2)'
> > You get to implement this version, because I think it's an awful idea.'ll

> hu? I'm not sure of when the Mercurial review process switched to from 
> "reviewers give feedback to submitter" to "reviewer can update submitter 
> patch them-self if they don't like it". That seems quite the opposite of 
> what you have been teaching us in the past 10 years.

I've always been aware that there's a risk that contributors will walk away if
I'm too nitpicky with their patches or ask them to make a change that they find
distasteful. And I've often taken imperfect or incomplete patches because of it.
Just so long as forward progress is made and no regressions are introduced.

In rare cases, where I find a feature desirable, but can't get a contributor to
do it to my satisfaction, I've written it myself (merge-tools comes to mind).
The downside of this approach is that there's no reason for the original
contributor to feel vested in it further, and I am thus on the hook for
maintaining it.

This extdata() proposal is a rather silly suggestion because every other
namespace in Mercurial already collides. And they collide intentionally because
it's convenient for users. We already have revset aliases creating the exact
same collision risk so the idea that a) extdata() is somehow protecting me from
something but b) I can still get the effect I want by also adding a revset alias
is a bit of a self-contradiction. Never mind that I put out an RFC on this topic
months ago and that the prototype has been in use for six.

But the real issue is that I am still completely exhausted with arguing with you
personally, so when you decided to latch on to this proposal, I was immediately
reminded of how much I was looking forward to doing other things with my time.

So I'm not going to write the extdata() version. You can either shrug and say "I
guess we won't have that feature" or you can do it.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH python-hglib v3] Allow hglib user to get call backs for prompts, output and errors

[Matt Mackall]

On Fri, 2016-10-28 at 22:24 +0900, Yuya Nishihara wrote:
> On Fri, 28 Oct 2016 11:35:27 +0100, Barry A. Scott wrote:
> > 
> > # HG changeset patch
> > # User Barry A. Scott 
> > # Date 1477650800 -3600
> > #  Fri Oct 28 11:33:20 2016 +0100
> > # Node ID dd7ce6a2c32d179eb2881d08e13d11631bf341fa
> > # Parent  6f15cb7cc9cb4427f35c60080f85dbf4ca5abd10
> > Allow hglib user to get call backs for prompts, output and errors.
> > 
> > setcbout(cbout), setcberr(cberr) and setcbprompt(cbprompt) are used to
> > set the call back function used by the hgclient class. cb stands for
> > call back.
> > 
> > cbout is a function that will be called with the stdout data of the
> > command as it runs. cbout is called with output as it is made available,
> > which can be as partial lines or multiple lines.
> > 
> > cberr is a function that will be called with the stderr data of the
> > command as it runs. cberr is called with output as it is made available,
> > which can be as partial lines or multiple lines.
> > 
> > Command that make remote connects can prompt for username and password
> > for HTTP/HTTPS connections.
> > 
> > cbprompt is called when hgclient need a response to a prompt from the
> > server. It receives the max number of bytes to return and the contents
> > of stdout received so far. The last text sent to either cbout or cberr
> > will contain the prompt text itself.
> I'm not a big fan of these APIs, but they look okay and solve the real
> problem, so seem good. Marked as pre-reviewed, thanks.

These and two other patches are pushed to hglib, thanks.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH 2 of 2 python-hglib] util: drop mutable default from popen()

[Matt Mackall]

On Wed, 2016-10-19 at 00:12 +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1476803147 -32400
> #  Wed Oct 19 00:05:47 2016 +0900
> # Node ID 50ce9593ec69508946fc2f9fc88d79a6b9bcfc33
> # Parent  1ec4c46d309dcaef7a9bab6415cacbc5caf72dfe
> util: drop mutable default from popen()

These are queued, thanks.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: Please make a python-glib release - is there a hold up?

[Matt Mackall]

On Thu, 2016-12-29 at 15:11 -0500, Augie Fackler wrote:
> At the moment, only mpm and idank (cc’ed) can do a release. Perhaps one of
> them can do so?

I've cut and pushed a 2.3 release, sorry for the delay. The official hglib repo
still lives on my server, so a bit of infra work will need to be done before
anyone else can properly cut a release.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH hglib RESEND] hglib: fix hg clone --uncompressed option typo (issue5458)

[Matt Mackall]

On Fri, 2017-03-24 at 10:05 -0400, Long Vu wrote:
> # HG changeset patch
> # User Long Vu 
> # Date 1490322881 14400
> #  Thu Mar 23 22:34:41 2017 -0400
> # Node ID 820d7c1e470aaa11dad8f33e9161179a8115cef6
> # Parent  ae38fb772613604dac7fcf63705e8a2a17ff50cd
> hglib: fix hg clone --uncompressed option typo (issue5458)

I've pushed this and made a 2.4 release, thanks.

-- 
Mathematics is the supreme nostalgia of our time.



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