[Bug 5337] New: "hg revert -i" can not revert part of hunk

[bugzilla]

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

Bug ID: 5337
   Summary: "hg revert -i" can not revert part of hunk
   Product: Mercurial
   Version: 3.9
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: record
  Assignee: bugzi...@selenic.com
  Reporter: martinv...@google.com
CC: mercurial-de...@selenic.com

Commit and empty file, add two lines to it, then try to revert one of the added
lines using "hg revert -i". Both lines will be reverted. Note that "hg commit
-i" can add correctly add either of the lines.

This shows the bug:

hg init
touch f
hg add f
hg ci -m empty
printf 'a\nb\n' > f
hg ci -i

Select one of the lines and confirm. Both will be reverted.

-- 
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

[PATCH 2 of 2] util: move checknlink away from the dependency of a hard-coded filename

[ttung]

# HG changeset patch
# User Tony Tung 
# Date 1471639931 25200
#  Fri Aug 19 13:52:11 2016 -0700
# Node ID 4aaeb57d5f4497ef35b48e23b80e43b914afd819
# Parent  2efc5a05d80a6d4253767f2ce0c2fb062ba83cb6
util: move checknlink away from the dependency of a hard-coded filename

This somewhat insulates us against bugs in checknlink when a stale file
left behind could result in checknlink always returning False.

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -1305,34 +1305,33 @@
 def checknlink(testfile):
 '''check whether hardlink count reporting works properly'''
 
+dirpath, filename = os.path.split(testfile)
+
 # testfile may be open, so we need a separate file for checking to
 # work around issue2543 (or testfile may get lost on Samba shares)
-f1 = testfile + ".hgtmp1"
-if os.path.lexists(f1):
-return False
+f1handle, f1path = tempfile.mkstemp(prefix=filename, dir=dirpath)
+os.close(f1handle)
+
+f2handle, f2path = tempfile.mkstemp(prefix=filename, dir=dirpath)
+os.close(f2handle)
+f2handle = None
+
+# there's a small race condition that another file can jam itself in 
between
+# the time we remove f2 and the time we create the hard link.  in the
+# unlikely scenario that happens, we'll treat it as nlink being unreliable.
 try:
-posixfile(f1, 'w').close()
-except IOError:
-try:
-os.unlink(f1)
-except OSError:
-pass
-return False
-
-f2 = testfile + ".hgtmp2"
-fd = None
-try:
-oslink(f1, f2)
+os.unlink(f2path)
+oslink(f1path, f2path)
 # nlinks() may behave differently for files on Windows shares if
 # the file is open.
-fd = posixfile(f2)
-return nlinks(f2) > 1
+f2handle = posixfile(f2path)
+return nlinks(f2path) > 1
 except OSError:
 return False
 finally:
-if fd is not None:
-fd.close()
-for f in (f1, f2):
+if f2handle is not None:
+f2handle.close()
+for f in (f1path, f2path):
 try:
 os.unlink(f)
 except OSError:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

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

[Matt Mackall]

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

Yes, that seems very useful.

-- 
Mathematics is the supreme nostalgia of our time.

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

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

[Yuya Nishihara]

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

What coal is doing should be valid even if we change the way of path resolution
of %include source. However, that's true someone could do %include paper/map
to replace all *.tmpl files by theirs.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 3] flags: allow specifying --boolean-flag=(true|false) on the command line (BC)

[Augie Fackler]

On Aug 19, 2016, at 09:02, Augie Fackler  wrote:
> On Aug 18, 2016, at 15:52, Kyle Lippincott  wrote:
>> On Thu, Aug 18, 2016 at 9:13 AM, Augie Fackler  wrote:
>> # HG changeset patch
>> # User Augie Fackler 
>> # Date 1471534453 14400
>> #  Thu Aug 18 11:34:13 2016 -0400
>> # Node ID 9ec3aad0bf74ad1c25e87bcd0f536896d1c355ca
>> # Parent  8ed7fdc716ffc95a4062875eafc2739697122fbc
>> flags: allow specifying --boolean-flag=(true|false) on the command line (BC)
>> 
>> Do we want to describe this (in this description) as supporting all of the 
>> things parseable by parsebool?  Not sure how much it matters to be 
>> pedantically correct in the descriptions.
> 
> Probably should be in the commit message, yeah.
> 
>> Is there documentation that needs to be updated to mention this is now 
>> possible?  (might be already done in another change in this series, but I 
>> didn't see it)
> 
> I'm honestly not sure where to tuck this doc-wise, given that it matters for 
> all boolean flags everywhere. Sigh. I'm very open to ideas...

Here's one idea. I don't know how clear it is though. Left side of the diff is 
what we have today, right side of the diff is what I'm proposing. I don't love 
it, but maybe it helps?

Kind of ugly though. Sigh.

augie% diff -u <(hg help update) <(./hg help update)
--- /dev/fd/11  2016-08-19 09:26:16.0 -0400
+++ /dev/fd/12  2016-08-19 09:26:16.0 -0400
@@ -31,11 +31,11 @@

 options:

- -C --clean  discard uncommitted changes (no backup)
- -c --check  require clean working directory
- -d --date DATE  tipmost revision matching date
- -r --rev REVrevision
- -t --tool VALUE specify merge tool
---mq operate on patch repository
+ -C --clean[=(true|false)] discard uncommitted changes (no backup)
+ -c --check[=(true|false)] require clean working directory
+ -d --date DATEtipmost revision matching date
+ -r --rev REV  revision
+ -t --tool VALUE   specify merge tool
+--mq[=(true|false)]operate on patch repository

 (some details hidden, use --verbose to show complete help)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 3] flags: allow specifying --boolean-flag=(true|false) on the command line (BC)

[Augie Fackler]

> On Aug 18, 2016, at 15:52, Kyle Lippincott  wrote:
> 
> 
> 
> On Thu, Aug 18, 2016 at 9:13 AM, Augie Fackler  > wrote:
> # HG changeset patch
> # User Augie Fackler >
> # Date 1471534453 14400
> #  Thu Aug 18 11:34:13 2016 -0400
> # Node ID 9ec3aad0bf74ad1c25e87bcd0f536896d1c355ca
> # Parent  8ed7fdc716ffc95a4062875eafc2739697122fbc
> flags: allow specifying --boolean-flag=(true|false) on the command line (BC)
> 
> Do we want to describe this (in this description) as supporting all of the 
> things parseable by parsebool?  Not sure how much it matters to be 
> pedantically correct in the descriptions.

Probably should be in the commit message, yeah.

> Is there documentation that needs to be updated to mention this is now 
> possible?  (might be already done in another change in this series, but I 
> didn't see it)

I'm honestly not sure where to tuck this doc-wise, given that it matters for 
all boolean flags everywhere. Sigh. I'm very open to ideas...

> 
> 
> This makes it much easier to enable some anti-foot-shooting features
> (like update --check) by default, because now all boolean flags can be
> explicitly disabled on the command line without having to use HGPLAIN
> or similar.
> 
> diff --git a/mercurial/fancyopts.py b/mercurial/fancyopts.py
> --- a/mercurial/fancyopts.py
> +++ b/mercurial/fancyopts.py
> @@ -10,7 +10,10 @@ from __future__ import absolute_import
>  import getopt
> 
>  from .i18n import _
> -from . import error
> +from . import (
> +error,
> +util,
> +)
> 
>  def gnugetopt(args, options, longoptions):
>  """Parse options mostly like getopt.gnu_getopt.
> @@ -91,6 +94,10 @@ def fancyopts(args, options, state, gnu=
>  short += ':'
>  if oname:
>  oname += '='
> +else:
> +prefix = '--' + oname + '='
> +if any(a.startswith(prefix) for a in args):
> +oname += '='
>  if short:
>  shortlist += short
>  if name:
> @@ -121,7 +128,10 @@ def fancyopts(args, options, state, gnu=
>  elif t is type([]):
>  state[name].append(val)
>  elif t is type(None) or t is type(False):
> -state[name] = True
> +if val:
> +state[name] = util.parsebool(val)
> +else:
> +state[name] = True
> 
>  # return unparsed args
>  return args
> diff --git a/tests/test-update-branches.t b/tests/test-update-branches.t
> --- a/tests/test-update-branches.t
> +++ b/tests/test-update-branches.t
> @@ -379,3 +379,14 @@ Test experimental revset support
> 
>$ hg log -r '_destupdate()'
>2:bd10386d478c 2 (no-eol)
> +
> +Test that boolean flags allow --flag=false specification to override 
> [defaults]
> +  $ cat >> $HGRCPATH < +  > [defaults]
> +  > update = --check
> +  > EOF
> +  $ hg co 2
> +  abort: uncommitted changes
> +  [255]
> +  $ hg co --check=no 2
> +  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> ___
> 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

[Bug 5336] New: Add a --future option to blame/annotate to find future changes to lines in a file

[bugzilla]

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

Bug ID: 5336
   Summary: Add a --future option to blame/annotate to find future
changes to lines in a file
   Product: Mercurial
   Version: 3.7.3
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@selenic.com
  Reporter: maxgrenderjo...@gmail.com
CC: mercurial-de...@selenic.com

hg annotate/blame is used to answer the common question:

'Whenever/whoever added/changed this line broke my build - when/who was it'?

I often have a similar, related question:

'Whenever this line changed from what it was as of revision xyz broke my build
- when/who was it'?

i.e. I want a command that does just what hg annotate does, only instead of
listing the revision that made the line what it was, it shows the next revision
that changes the line from what it currently is. Paging through all the
revisions to a file to find the first one where a particular line of interest
changes can be very painful and error prone. Doing a diff between the current
version of the file and some version far in the future requires you to then do
a binary search to find when the change was made, and can be even harder if the
change was to remove the line entirely (in which case `hg annotate` from the
the file in the future can't help you).

It would appear that I'm not the only one with this issue, which is currently
answered with workarounds at best on stackoverflow:
http://stackoverflow.com/questions/13549555/mercurial-how-to-see-history-for-specific-line-of-code

I can imagine there might be technical challenges - which branch do you follow
if that file branches in the future, but hopefully some sensible defaults could
be devised (e.g. force the user to pick branches to follow or simply fail if
that file is branched in the future)

Perhaps there's already a neat way of doing this - if so, please post it on
stackoverflow!

-- 
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

[Bug 5335] New: Unexpected behaviour while using --with-python3

[bugzilla]

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

Bug ID: 5335
   Summary: Unexpected behaviour while using --with-python3
   Product: Mercurial
   Version: 3.9-rc
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@selenic.com
  Reporter: 7895pul...@gmail.com
CC: mercurial-de...@selenic.com

I noticed this fixing the raise statement in mercurial/bundle2.py. The commit
which got pushed can be seen here https://www.selenic.com/hg/rev/e584c6235500.
There is test-bundle2-format.t which will fail we haven't raised the exception
correctly.
Now if we intentionally try to fail the test on python 3 by changing the lines
of code in python 3 if block, what I tried was replacing with `raise abc`, and
run the test on python 3, the test passes, which should not.
If we try changing the statement in py2 else block and change it to something
like `raise abc`, and then run the test on python 3, we should expect the test
to pass, as we are not using python 2, but the test fails.
What seems is like even using --with-python3 the tests are running on python 2
only. Maybe something is missing in implementation.

-- 
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