[Bug 5474] New: Version info on website is outdated

[mercurial-bugs]

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

Bug ID: 5474
   Summary: Version info on website is outdated
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: website
  Assignee: bugzi...@mercurial-scm.org
  Reporter: mar...@python-blog.com
CC: mercurial-de...@selenic.com

Hi,

Usually when RC release was out the main website exposed that download. I think
more people would know about it and test the RC release.

Currently on main website it shows latest version is 4.0.1, despite 4.0.2 and
4.1-rc are available.


I think at latest 4.0.2 should be there if not the 4.1-rc for better early
exposure.

-- 
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 5475] New: hg unshelve could ignore -n/--name

[mercurial-bugs]

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

Bug ID: 5475
   Summary: hg unshelve could ignore -n/--name
   Product: Mercurial
   Version: stable branch
  Hardware: Macintosh
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: shelve
  Assignee: bugzi...@mercurial-scm.org
  Reporter: joshg...@alum.mit.edu
CC: mercurial-de...@selenic.com

Typing "hg unshelve -n Patch", the operation is aborted with the error message.
   hg unshelve: option -n not recognized

I think it would be safe in this case to "do what I meant" and ignore the
-n/--name.

I have the habit of typing -n both from the old shelve extension, which I
believe required it, and from expecting consistency with shelve.  Also, it's
nice to be able to minimally edit the command line in the history.

I don't think this would need to be mentioned in the help.

-- 
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 5476] New: largefiles: hg add doesn't respect largefiles.minsize and largefiles.patterns

[mercurial-bugs]

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

Bug ID: 5476
   Summary: largefiles: hg add doesn't respect largefiles.minsize
and largefiles.patterns
   Product: Mercurial
   Version: 4.1
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: largefiles
  Assignee: bugzi...@mercurial-scm.org
  Reporter: abcz2.upr...@gmail.com
CC: mercurial-de...@selenic.com, nato...@gmail.com

I can't add largefiles other than with `hg add --large` in mercurial 4.1. I
guess this is regression, because numerous answers on stackoverflow show that
this worked in the past.

test.sh


REPO=large-fail
rm -rf $REPO
mkdir $REPO
(
  cd $REPO && hg init
  dd if=/dev/zero of=$PWD/all.mmf bs=1M count=9
  hg add --config extensions.largefiles=  \
 --config "largefiles.minsize=0" \
 --config "largefiles.patterns = re:.*" \
 --verbose --debug \
 all.mmf
  ls .hglf
)

Output:

$ ./test.sh
9+0 records in
9+0 records out
9437184 bytes (9.4 MB, 9.0 MiB) copied, 0.00525248 s, 1.8 GB/s
adding all.mmf
ls: cannot access '.hglf': No such file or directory


Expected:

$ ./test.sh
9+0 records in
9+0 records out
9437184 bytes (9.4 MB, 9.0 MiB) copied, 0.00487904 s, 1.9 GB/s
adding all.mmf as a largefile
all.mmf

-- 
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 5477] New: allow setting indirect colors / color "aliases"

[mercurial-bugs]

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

Bug ID: 5477
   Summary: allow setting indirect colors / color "aliases"
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: color
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-de...@selenic.com

It would be nice to be able to compose an 'indirect' color or a 'conceptual'
color out of other colors / codes, and refer to that instead of repeating the
raw stuff all the time.

Currently, color.foo only accepts integers.  We can't do something like
color.brightblack = bold black, and then use 'brightblack' elsewhere in our
color settings, letting people override 'color.brightblack = 8' if they have a
terminal that treats bold as bold-and-not-high-intensity (like Terminal.app),
or a terminal that swaps 30 and 37 if it's run with -rv to get a white
background.

-- 
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 5478] New: html docu lacks the images

[mercurial-bugs]

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

Bug ID: 5478
   Summary: html docu lacks the images
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: g...@axiros.com
CC: mercurial-de...@selenic.com,
pierre-yves.da...@ens-lyon.org

hi, many images are missing in the current docu build.

E.g. https://www.mercurial-scm.org/doc/evolution/sharing.html and other pages
lacks the .svg images.

These are all in the current sphinx build: (4.feb 2017)

https://www.mercurial-scm.org/doc/evolution/_images/

Think just the user guide, on the other pages I get instead of the image like:

"
So the picture in public is much simpler than in either dev-repo or test-repo.
Neither our missteps nor our amendments are publicly visible, just the final,
beautifully polished changeset:

[figure SG05: public repo with rev 0:0dc9, 1:de61, both public]
"



PS: Sorry for the lousy formatting, don't know what markup format bugzilla
usess :-/

-- 
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 5479] New: `hg diff --stat` gets confused by lines that start with "-- " or "++ "

[mercurial-bugs]

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

Bug ID: 5479
   Summary: `hg diff --stat` gets confused by lines that start
with "-- " or "++ "
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-de...@selenic.com

Created attachment 1947
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1947&action=edit
test that shows the issue (as patch from test-diffstat.t)

Note: possible duplicate of 1123?  That claims that diffstat was an external
tool, though, so while the issue might be similar, I don't think it's a strict
duplicate.

If a line in a file starts with "-- " and is changed, `hg diff --stat` doesn't
count it as a deletion.  Similarly, if the new version of the line starts with
"++ ", it is not counted as an addition.  This can lead to diffstat claiming 0
diffs even if there are some:

  $ hg diff --root .
  diff -r 32e517bb8958 file
  --- a/fileThu Jan 01 00:00:00 1970 +
  +++ b/file* (glob)
  @@ -1,3 +1,3 @@
   line 1
  --- line 2, with dashes
  +++ line 2, switched dashes to plusses
   line 3
This is wrong: does not count either, because both lines look like file
headers.
  $ hg diff --root . --stat
   file |  0
   1 files changed, 0 insertions(+), 0 deletions(-)

-- 
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 5480] New: Manifest grows out of control in large repository with hundreds of branches, regular merges and a refactor involving 1000s of file moves

[mercurial-bugs]

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

Bug ID: 5480
   Summary: Manifest grows out of control in large repository with
hundreds of branches, regular merges and a refactor
involving 1000s of file moves
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-de...@selenic.com

We have a very large internal repository with 3+ files in the tip, 100+
active branches with regular merges between them, and almost 6 revisions.

Last year, we undertook a large refactoring of our code that caused _all_ files
in the repository to be moved to new locations (the entire code tree was
rearranged into a logical scheme). Some older maintenance branches have
branched out before the refactor, so they still have the old layout; we still
have to regularly merge from these branches into our main trunk, which is
refactored.

Since approximately the start of this refactor, our manifest file has started
growing out of control, similar to how it behaved prior to generaldelta.
Enabling aggressivemergedeltas doesn't appear to help - it shrinks the manifest
from 1.3GB to 1GB, which is still far higher than the ~100MB we had around rev
43000

Looking at the revlog shows that around that time, the average delta chain
length dropped from the low thousands to the low double digits. Many revisions
since then are stored as old-style (r-1) deltas instead of being deltified
against a parent. The culprit appears to be the "dest" check in _isgooddelta,
which often goes above textlen*4 due to intervening revisions from other
branches, and causes otherwise good deltas to be discarded.

According to a comment in the code, the "dest" check is supposed to provide an
upper bound to the I/O needed to read a revision later, but it's calculated
using an algorithm that gives a reasonable upper bound only with the old (r-1)
delta format. With generaldelta, it erroneously counts unrelated revisions in
between revisions of the delta chain, and gives an unreasonably high upper
bound. Thus, many good deltas are rejected, and the resulting suboptimal
storage further spreads out the delta chains in the revlog, causing yet more
"dest" false positives, and thus even worse compression. Eventually,
performance degrades to that before generaldelta.

A proof-of-concept fix (simply dropping the dest check) allows the manifest to
shrink to ~150MB, and further down to ~60MB with aggressivemergedeltas enabled.

-- 
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 5481] New: With aggressivemergedeltas=False, one merge parent is ignored for delta generation even if the other parent is unsuitable

[mercurial-bugs]

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

Bug ID: 5481
   Summary: With aggressivemergedeltas=False, one merge parent is
ignored for delta generation even if the other parent
is unsuitable
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-de...@selenic.com

The algorithm for finding the right delta base for a merge is subtly wrong when
aggressivemergedeltas is False. We pick the higher-numbered of the two merge
parent revisions, check if it produces a viable delta, and if not, we fall back
straight to a rev-1 delta without ever looking at the other parent.

In a merge, one of the parents is typically an excellent candidate for the
delta base, while the other may be no worse than a random revision. It's
difficult to predict the optimal parent without actually calculating the deltas
for both.

Since we chose against making aggressivemergedeltas the default, we can't
always guarantee an optimal parent choice. However, there is room for
improvement:
- We select the parent to use based on revision number, or "tipmostness". This
is not a good predictor of which parent is optimal - indeed, in a pull request
scenario, it tends to select the "incoming" parent, which may have branched out
far in the past, and is a rather poor delta base candidate. Instead, we should
compare the DAG distances from a common ancestor, and pick the larger one as
the delta parent.
- If the selected parent turns out to be unsuitable (e.g. too long delta
chain), the other parent is still a better candidate than rev-1. We should fall
back to it, and only try rev-1 if we have exhausted both parents. This behavior
is still different from aggressivemergedeltas, as it accepts the first tested
parent to give a good delta, and only moves on to the other one if the first
delta is rejected, as opposed to always generating both deltas and picking the
smaller one. So, the performance hit should be negligible.

-- 
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 5482] New: revlog._chunks wastes IO for discontiguous delta chains

[mercurial-bugs]

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

Bug ID: 5482
   Summary: revlog._chunks wastes IO for discontiguous delta
chains
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-de...@selenic.com

revlog._chunks always converts its incoming parameter revs into a single
(start, end) pair for passing to _chunkraw. This is/was fine in
non-generaldelta revlogs since delta chains there are guaranteed to be
contiguous.

However, generaldelta allows delta chains to be discontiguous. In this case,
reading a contiguous range wastes IO. To avoid wasting too much IO, we
currently limit delta chains to span no more than 4 compressed full revisions'
worth of data, which severely hurts compression in highly branched repositories
(see bug 5480).

We should instead split up revs into contiguous subranges and _chunkraw them
individually, or at least (if perf reasons require) skip "large" gaps between
ranges. I'd suggest defining "large" as more than C * (compresseddeltalen /
(len(subranges)-1)), where C is a config option with a default value to be
determined experimentally. C needs to be configurable because the optimal C
will likely be different for an HDD vs an SSD - indeed, C=0 is probably best
for SSDs.
Again, it would be best if we could just skip all gaps, but I don't know how
that will affect performance.

-- 
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 5483] New: Move "Mercurial" to the top of the Component list on Bugzilla

[mercurial-bugs]

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

Bug ID: 5483
   Summary: Move "Mercurial" to the top of the Component list on
Bugzilla
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: infrastructure
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: kbullock+mercur...@ringworld.org,
mercurial-de...@selenic.com

It would be nice if the Mercurial core project were on the top of the component
list, since it probably receives the most bug reports. Even having it on the
bottom of the list would be better than in the middle alphabetically, which
requires manual scrolling for every bug report.

-- 
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 5484] New: "hg debugupgraderepo" misses some optimizations on already-generaldelta repos

[mercurial-bugs]

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

Bug ID: 5484
   Summary: "hg debugupgraderepo" misses some optimizations on
already-generaldelta repos
   Product: Mercurial
   Version: 4.1
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-de...@selenic.com

With the PoC fix for bug 5480, if I call "debugupgraderepo" on a fresh
generaldelta clone of our heavily-affected main repo, the manifest.d file
compresses down to 57MB (down from 1.3GB).

If I instead make that fresh clone non-generaldelta (using
format.generaldelta=0, format.usegeneraldelta=0), and then run
"debugupgraderepo" with the same settings, the manifest.d file goes down to
31MB.

Looks like there is some extra optimization done when converting from
non-generaldelta to generaldelta, which is not available when
upgrading/optimizing an existing generaldelta repo.

The debugupgraderepo command line I used was:
hg --config extensions.deltafix=C:\nngutilsm\hgext\deltafix.py --config
format.aggressivemergedeltas=1 debugupgraderepo --optimize redeltaparent --run

(deltafix.py is the PoC fix for bug 5480, packaged as an extension)

This same command yields a smaller manifest when upgrading the non-generaldelta
clone than when optimizing the already-generaldelta clone.

My guess is that this has to do with delta reordering when a non-generaldelta
revlog is cloned with format.generaldelta=1. We should be able to do the same
for already-generaldelta revlogs either automatically when --optimize
redeltaparent is set, or with a new --optimize reorderdeltas option.

-- 
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 5485] New: Default hgrc generated on clone references the obsolete "default-push" path

[mercurial-bugs]

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

Bug ID: 5485
   Summary: Default hgrc generated on clone references the
obsolete "default-push" path
   Product: Mercurial
   Version: 4.1
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-de...@selenic.com

Default-push is deprecated in favor of default:pushurl. Yet, "hg clone" still
inserts this in every hgrc file it creates:

# path aliases to other clones of this repo in URLs or filesystem paths
# (see 'hg help config.paths' for more info)
#
# default-push = ssh://j...@example.net/hg/jdoes-fork
# my-fork  = ssh://j...@example.net/hg/jdoes-fork
# my-clone = /home/jdoe/jdoes-clone

We should update this message.

-- 
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 5486] New: Mercurial+evolve sometimes segfaults on pull

[mercurial-bugs]

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

Bug ID: 5486
   Summary: Mercurial+evolve sometimes segfaults on pull
   Product: Mercurial
   Version: 4.1
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: a...@dwimlabs.net
CC: mercurial-de...@selenic.com,
pierre-yves.da...@ens-lyon.org

I have a box that mirrors some repos, including Mercurial's main, once a day by
cron and occasionally, very rarely, hg pull segfaults on that repo. It's the
only repo that uses evolve and the only that has ever failed a pull. hg version
is 4.1 (installed from the ppa), evolve summary is:

parent: 1803:54120614e9e5 
 Update  tag 5.6.0 for changeset e7b6e9c4a5d4
branch: stable
bookmarks: @
commit: (clean)
update: (current)

The very rare segfaults have been happening before, but I used to have hg pull
--quiet in the cron job to not get too much mail. Here is a recent segfault
with `hg pull --verbose`:

pulling from https://www.mercurial-scm.org/repo/hg/
searching for changes
all local heads known remotely
sampling from both directions
sampling from both directions
adding changesets
adding manifests
adding file changes
added 23 changesets with 41 changes to 10 files
Segmentation fault

Now the repo has an abandoned transaction.

For comparison, here's the output from a day before, when it worked fine:

pulling from https://www.mercurial-scm.org/repo/hg/
searching for changes
all local heads known remotely
sampling from both directions
sampling from both directions
adding changesets
adding manifests
adding file changes
added 27 changesets with 54 changes to 32 files
111 new obsolescence markers
updating bookmark @
(run 'hg update' to get a working copy)

-- 
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 5487] New: Cannot restore merge commit after rebase

[mercurial-bugs]

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

Bug ID: 5487
   Summary: Cannot restore merge commit after rebase
   Product: Mercurial
   Version: 4.0.2
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: abcz2.upr...@gmail.com
CC: mercurial-de...@selenic.com,
pierre-yves.da...@ens-lyon.org

I've done a rebase of a merge commit. I was not satisfied with it, so I'd like
to restore previous version and strip current. But I have evolution enabled, so
no backup was generated.

Here is my changeset

$ hg.exe --hidden log -r "obsolete()"
changeset:   4433:05cee9113122
parent:  4427:f16ee9507a9b
parent:  4432:4d1ecbeabed5
user:danbst
date:Thu Feb 16 06:29:11 2017 +0200
summary: Merge with release-test

When I try to recover it (using hg touch), I get:

$ hg.exe --hidden touch -r 4433
[4433] Merge with release-test
reviving this changeset will create divergence unless you make a duplicate.
(a)llow divergence or (d)uplicate the changeset?  a
abort: cannot amend merge changesets

But if I try duplicate:

$ hg.exe --hidden touch -D -r 4433
abort: cannot amend merge changesets

So, no way to recover it, and no backups

-- 
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 5488] New: mercurial/help/internals/revlogs.txt seems to be wrong about chain base

[mercurial-bugs]

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

Bug ID: 5488
   Summary: mercurial/help/internals/revlogs.txt seems to be wrong
about chain base
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: z...@zash.se
CC: mercurial-de...@selenic.com

Created attachment 1949
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1949&action=edit
Patch, attempt to improve the text

mercurial/help/internals/revlogs.txt states that for the chain base field, "-1
means this revision holds full text", but the code in revlog.chainbase() and
revlog._deltachain() seems to stop when this field is equal to its own revision
id.

-- 
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 5489] New: AclExtension: Support pattern matching for branch rules

[mercurial-bugs]

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

Bug ID: 5489
   Summary: AclExtension: Support pattern matching for branch
rules
   Product: Mercurial
   Version: 3.9
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: nikolaos.gki...@googlemail.com
CC: mercurial-de...@selenic.com

This feature wish refers to the AclExtension. However, this extension does not
have an entry in the component list of this Bugzilla. I hope it assigning it to
the Mercurial component was right.

The "hg help acl" documentation states the following:

##
#Branch-based Access Control
#---
#
#Use the "acl.deny.branches" and "acl.allow.branches" sections to have #branch-
#based access control. Keys in these sections can be either:
#
#- a branch name, or
#- an asterisk, to match any branch;
#
#The corresponding values can be either:
#
#- a comma-separated list containing users and groups, or
#- an asterisk, to match anyone;
#
#You can add the "!" prefix to a user or group name to invert the sense of #the
#match.
###

The request is to implement simple pattern matching for the branch name. This
would enable you to set rules for a variable number of branches matching a
certain pattern. For example the hgrc entry could look like this:

##
#[acl.allow.branches]
#release/* = @reviewers
##

This example would allow the reviewers group only to do work on branches whose
name starts with "release/*".

A question regarding a feature like this one was posted to StackExchange in
2011 (http://superuser.com/questions/249453/mercurial-set-up-acl). It was
suggested to file a feature wish but I could not find one regarding this
feature. So here is mine. I hope it can be implemented. Thanks for your time!

-- 
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 5490] New: Debian/Ubuntu hg package version not up to date

[mercurial-bugs]

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

Bug ID: 5490
   Summary: Debian/Ubuntu hg package version not up to date
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: heatherjboo...@gmail.com
CC: mercurial-devel@mercurial-scm.org

tl;dr: Debian/Ubuntu package longs for its friend fsmonitor

I'm not sure if this is the place for this, but it seems that running `apt-get
install mercurial` as proposed in the docs to download/install Mercurial
installs v 3.7.3 instead of a newer version, and because fsmonitor becomes part
of the core package as of 3.8, it would be great to get that automatically. 

Running `apt-cache show mercurial` says (among other things): "Version:
3.7.3-1ubuntu1".

Please let me know if I can give more info or be of assistance!

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

[Bugzilla] Your account mercurial-devel@mercurial-scm.org is being impersonated

[mercurial-bugs]

Kevin Bullock  has used the 'sudo' 
feature to access 
Bugzilla using your account.

Kevin Bullock  provided the following 
reason for doing this:
kbullock+mercur...@ringworld.org

If you feel that this action was inappropriate, please contact 
ad...@mercurial-scm.org.  For more information on this feature, 
visit .
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5491] New: A bad pager config results in a cryptic error

[mercurial-bugs]

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

Bug ID: 5491
   Summary: A bad pager config results in a cryptic error
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org

With the in-core pager, and a bad env config on Windows (and OS X, per Augie):

C:\Users\Matt\Projects\hg>set PAGER=less

C:\Users\Matt\Projects\hg>hg help filesets
'less' is not recognized as an internal or external command,
operable program or batch file.

Augie's thoughts on the ML:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/093600.html

-- 
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 5492] New: Mercurial does not preserver unix ACL in '.hg.'

[mercurial-bugs]

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

Bug ID: 5492
   Summary: Mercurial does not preserver unix ACL in '.hg.'
   Product: Mercurial
   Version: 4.1
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: pierre-yves.da...@ens-lyon.org
CC: mercurial-devel@mercurial-scm.org

Mercurial is successfully preserving the unix standard permission of file in
'.hg/' (it us the same one as the one on '.hg/') but it does not perserve the
unix ACL.

Note that many unix tool also ignores ACL so Mercurial is not doing especially
bad here. In addition ACL support is non-trivial since Python itself does not
support interacting with ACL natively.

But it is still worth tracking the issue, we might be able to do some progress.
There is a Python module to handle ACL (https://pypi.python.org/pypi/PyACL). We
could add support for ACL preservation if the module exists and maybe vendor
it?

-- 
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 5493] New: ISAPI_WSGI module not work anymore in 4.1 version

[mercurial-bugs]

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

Bug ID: 5493
   Summary: ISAPI_WSGI module not work anymore in 4.1 version
   Product: Mercurial
   Version: stable branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: hgweb
  Assignee: bugzi...@mercurial-scm.org
  Reporter: vbolsha...@gmail.com
CC: mercurial-devel@mercurial-scm.org

ISAPI_WSGI module build from 4.1 version not starting with this message:

Internal Extension Error: Failed to import callback module 'hgwebdir_wsgi'
Traceback (most recent call last):
  File "D:\Mercurial\NEW\hgwebdir_wsgi.py", line 27, in 
from mercurial.hgweb.hgwebdir_mod import hgwebdir
  File
"D:\AppPython\hg\Lib\site-packages\mercurial-4.1-py2.7-win-amd64.egg\mercurial\hgweb\__init__.py",
line 13, in 
from ..i18n import _
  File
"D:\AppPython\hg\Lib\site-packages\mercurial-4.1-py2.7-win-amd64.egg\mercurial\i18n.py",
line 15, in 
from . import (
  File
"D:\AppPython\hg\Lib\site-packages\mercurial-4.1-py2.7-win-amd64.egg\mercurial\encoding.py",
line 15, in 
from . import (
  File
"D:\AppPython\hg\Lib\site-packages\mercurial-4.1-py2.7-win-amd64.egg\mercurial\pycompat.py",
line 168, in 
sysargv = sys.argv
AttributeError: 'module' object has no attribute 'argv'

Same ISAPI_WSGI module build from 4.0.2 version work without any problems.

-- 
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 5494] New: resolve --list continues to display results after rebase completes

[mercurial-bugs]

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

Bug ID: 5494
   Summary: resolve --list continues to display results after
rebase completes
   Product: Mercurial
   Version: 4.1-rc
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: rebase
  Assignee: bugzi...@mercurial-scm.org
  Reporter: r...@fb.com
CC: mercurial-devel@mercurial-scm.org

In some circumstances after a rebase, the merge state is not properly removed,
and `hg resolve --list` continues to show files as "resolved" when there should
no longer be a merge state at all.

This inside of a test file reproduces the problem:

"""
  $ cat >> $HGRCPATH < [extensions]
  > rebase=
  > EOF
  $ hg init repo
  $ cd repo
  $ echo a >> a
  $ hg commit -qAm base
  $ echo b >> a
  $ hg commit -qm b
  $ hg up .^
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ echo c >> a
  $ hg commit -qm c
  $ hg rebase -s 1 -d 2 --noninteractive
  rebasing 1:fdaca8533b86 "b"
  merging a
  warning: conflicts while merging a! (edit, then use 'hg resolve --mark')
  unresolved conflicts (see hg resolve, then hg rebase --continue)
  [1]
  $ echo a > a
  $ echo c >> a
  $ hg resolve --mark a
  (no more unresolved files)
  continue: hg rebase --continue
  $ hg rebase --continue
  rebasing 1:fdaca8533b86 "b"
  note: rebase of 1:fdaca8533b86 created no changes to commit
  saved backup bundle to
$TESTTMP/repo/.hg/strip-backup/fdaca8533b86-7fd70513-backup.hg (glob)
  $ hg resolve --list
  R a
  $ ls .hg/merge
  86f7e437faa5a7fce15d1ddcb9eaeaea377667b8
  state
  state2
"""

Note that .hg/merge should have been deleted but it wasn't, and that the
user-visible error here is that `hg resolve --list` shows a file when there
should be no merge state at all.

-- 
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 5495] New: No way to ask hg to update to a bookmark?

[mercurial-bugs]

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

Bug ID: 5495
   Summary: No way to ask hg to update to a bookmark?
   Product: Mercurial
   Version: 3.8.2
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: bookmarks
  Assignee: bugzi...@mercurial-scm.org
  Reporter: aalekse...@janestreet.com
CC: mercurial-devel@mercurial-scm.org

I want to tell hg to update to a certain bookmark and activate it. I think
there is no way to do it with hg update.

Let's say the bookmark I want to update to is called "x-y" (without quotes).

The most straightforward way:

$ hg update "x-y" 

can succeed even if no such bookmark exist: it will happily update to a
revision that's present in x but not in y instead of failing with "unknown
revision 'x-y'".
It can also update to not-what-you-want in some cases even if the bookmark
exists, for example:

$ crazy_bookmark=$(hg log -r .^ --template '{node}'); hg book
"$crazy_bookmark"; hg up "$crazy_bookmark"

(In fact this comes with a bonus bug: after you do this hg gets confused and it
thinks it's both on bookmark $crazy_bookmark and on revision $crazy_bookmark!)

The less straightforward ways leave the bookmark inactive:

$ hg update 'bookmark("x-y")'
$ hg update '"x-y"'

-- 
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 5496] New: Unable to clone repo published by ISAPI_WSGI module over HTTPS with client cert auth on Windwows server with local differ from en_US

[mercurial-bugs]

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

Bug ID: 5496
   Summary: Unable to clone repo published by ISAPI_WSGI module
over HTTPS  with client cert auth on Windwows server
with local differ from en_US
   Product: Mercurial
   Version: 4.0.2
  Hardware: PC
OS: Other
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: hgweb
  Assignee: bugzi...@mercurial-scm.org
  Reporter: vbolsha...@gmail.com
CC: mercurial-devel@mercurial-scm.org

Mercurial repository published on Windows Server 2016/2012 R2 as ISAPI_WSGI
module. Web site binded to HTTPS only and required SSL client cert.
encoding = UTF-8 in hgweb.config


User cert and key added to on mercurial.ini on windows and to hgrc on linux
(Ubuntu Server 16.04).

Cloning repository on windows done without problems (regarding "client" and
"server" locale). hg version 3.8.1.

Cloning repository on Linux (Ubuntu Server 16.04) with hg version 3.7.3 and
LANG=en_US.UTF-8

Stop with this message:
abort: HTTP Error 403: Forbidden

And this is last GET from client according to IIS log
GET /hg/A cmd=capabilities 443 -

When client cert requirements disabled on web server cloning work without
problems.

-- 
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 5497] New: "IndexError: list index out of range" when attempting to resolve merge conflicts

[mercurial-bugs]

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

Bug ID: 5497
   Summary: "IndexError: list index out of range" when attempting
to resolve merge conflicts
   Product: Mercurial
   Version: 4.1.1
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: richard.ever...@lanternpay.com
CC: mercurial-devel@mercurial-scm.org

When attempting to resolve a merge conflict (either following an unshelve, or
merge from another branch) I get the following error:

#!python
** Mercurial version (4.1).  TortoiseHg version (4.1)
** Command: --nofork commit
** CWD: C:\src\aces.server
** Encoding: cp1252
** Extensions loaded: eol, shelve
** Python version: 2.7.10 (default, May 23 2015, 09:44:00) [MSC v.1500 64
bit (AMD64)]
** Windows version: sys.getwindowsversion(major=6, minor=2, build=9200,
platform=2, service_pack='')
** Processor architecture: x64
** Qt-4.8.7 PyQt-4.11.4 QScintilla-2.9
Traceback (most recent call last):
  File "tortoisehg\hgqt\status.pyo", line 394, in reloadComplete
  File "tortoisehg\hgqt\status.pyo", line 424, in updateModel
  File "mercurial\merge.pyo", line 98, in read
  File "mercurial\merge.pyo", line 170, in _read
IndexError: list index out of range

This was also happening in Mercurial 4.0.1. Merging in the same repo and
attempting to resolve the same conflicts on a colleague's machine - running
Mercurial 3.8.3 does not result in this issue.

-- 
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 5498] New: "roll" of histedit removed wrong changesets

[mercurial-bugs]

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

Bug ID: 5498
   Summary: "roll" of histedit removed wrong changesets
   Product: Mercurial
   Version: 4.1.1
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: histedit
  Assignee: bugzi...@mercurial-scm.org
  Reporter: aklitz...@gmail.com
CC: mercurial-devel@mercurial-scm.org

histedit will remove changesets with the example.


cd /tmp/
hg init dummy
cd dummy

echo "dummy" > dummy
hg add .
hg ci -m "test 1"

echo "dummy2" > dummy2
hg add .
hg ci -m "test 2"

hg up -r 0

echo "dummy3" > dummy3
hg add .
hg ci -m "test 3"

hg histedit

histedit shows a single line because it cannot handle the "draft" commit with
multiple heads. But if someone changes "pick" to "roll" Mercurial will do
strange things with the history.
That is really annoying since we use the "autoverb" feature and "roll" is
sometimes the default one.

Expected:
Print a warning like for "public" changesets and do nothing.

warning: histedit rules saved to: .hg/histedit-last-edit.txt
hg: parse error: cannot fold into public change XYZ





History before:

@  Änderung:2:07b8f0553759
|  Marke:   tip
|  Vorgänger:   0:16436d3d271d
|  Nutzer:  ABC
|  Datum:   Wed Mar 08 09:10:41 2017 +0100
|  Zusammenfassung: test 3
|
| o  Änderung:1:e28d5347a3f4
|/   Nutzer:  ABC
|Datum:   Wed Mar 08 09:10:41 2017 +0100
|Zusammenfassung: test 2
|
o  Änderung:0:16436d3d271d
   Nutzer:  ABC
   Datum:   Wed Mar 08 09:10:41 2017 +0100
   Zusammenfassung: test 1


History after:
@  Änderung:0:10905d80a643
   Marke:   tip
   Nutzer:  ABC
   Datum:   Wed Mar 08 09:10:41 2017 +0100
   Zusammenfassung: test 1

-- 
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 5499] New: on running command hg bzexport to create a patch

[mercurial-bugs]

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

Bug ID: 5499
   Summary: on running command hg bzexport to create a patch
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: paavinina...@gmail.com
CC: mercurial-devel@mercurial-scm.org

** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32
bi
t (Intel)]
** Mercurial Distributed SCM (version 3.7.3)
** Extensions loaded: strip, mq, purge, share, transplant, color, pager,
histedi
t, rebase, blackbox, firefoxtree, reviewboard, bzexport, push-to-try
Traceback (most recent call last):
  File "c:/mozilla-build/python/Scripts/hg", line 43, in 
mercurial.dispatch.run()
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
5
4, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
1
20, in dispatch
ret = _runcatch(req)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
1
91, in _runcatch
return _dispatch(req)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
9
24, in _dispatch
cmdpats, cmdoptions)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
6
81, in runcommand
ret = _runcommand(ui, options, cmd, d)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\extensions.py",
line
 195, in closure
return func(*(args + a), **kw)
  File "c:\mozilla-build\python\Lib\site-packages\hgext\pager.py", line 143, in
pagecmd
return orig(ui, options, cmd, cmdfunc)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\extensions.py",
line
 195, in closure
return func(*(args + a), **kw)
  File "c:\mozilla-build\python\Lib\site-packages\hgext\color.py", line 518, in
colorcmd
return orig(ui_, opts, cmd, cmdfunc)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
1
055, in _runcommand
return checkargs()
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
1
015, in checkargs
return cmdfunc()
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\dispatch.py", line
9
21, in 
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\util.py", line 991,
in check
return func(*args, **kwargs)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\extensions.py",
line
 195, in closure
return func(*(args + a), **kw)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\util.py", line 991,
in check
return func(*args, **kwargs)
  File "c:\mozilla-build\python\Lib\site-packages\hgext\mq.py", line 3517, in
mq
command
return orig(ui, repo, *args, **kwargs)
  File "c:\mozilla-build\python\Lib\site-packages\mercurial\util.py", line 991,
in check
return func(*args, **kwargs)
  File
"c:/Users/hp/.mozbuild/version-control-tools/hgext\bzexport\__init__.py",
 line 915, in bzexport
if desc[0] in ['-', ':', '.']:
IndexError: string index out of range

-- 
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 5500] New: histedit --abort does unsafe history writing

[mercurial-bugs]

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

Bug ID: 5500
   Summary: histedit --abort does unsafe history writing
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: histedit
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arcppzju+hg...@gmail.com
CC: mercurial-devel@mercurial-scm.org

With experimental.evolution=createmarkers, histedit --abort still uses the
traditional unsafe strip(). It should create markers instead.

-- 
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 5501] New: Pager enabled now when people thought it was disabled

[mercurial-bugs]

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

Bug ID: 5501
   Summary: Pager enabled now when people thought it was disabled
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-devel@mercurial-scm.org

Important information that's relevant:

- this is happening at a company that pushes a centralized configuration
- that centralized configuration has historically enabled pager by these
configs:
- - extensions.pager=
- - pager.pager = less -FRX
- - pager.attend = 


We're rolling 4.1.1+290-7433b3bc55ee to our users (I can try to identify what
we previously had if it's relevant, but this is the first time we're picking up
the pager changes), and have two reports of users complaining because they
thought they'd disabled pager but now it's enabled again.

One user disabled it via 'extensions.pager=!'  (exclamation mark on the end ->
don't load extension)

One user disabled it via 'pager.attend = NONE'.


Both of the users that have raised the issue internally are now happy with
'pager.enable = False', but I wanted to file a bug since this is a set of
potentially unexpected changes, and to see if we wanted to do anything about
it.  Note: it doesn't require a company-wide centralized configuration, it
might be, for example, part of the OS distribution: if any common distribution
turns pager on for people and thus these kinds of "turn pager off" methods have
been put into people's hgrc files, we're now not respecting them.

Resolving as WONTFIX [behavior change is expected/intended/acceptable] is
probably OK, but I'd like someone who knows more about *exactly* what the BC
guarantees are to investigate before this gets closed :)

-- 
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 5502] New: Empty commit diff

[mercurial-bugs]

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

Bug ID: 5502
   Summary: Empty commit diff
   Product: Mercurial
   Version: 4.1.1
  Hardware: Macintosh
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: smos...@gmail.com
CC: mercurial-devel@mercurial-scm.org

Hello!
I face such behaviour on 4.1.1 as well as on 3.8.3 version:
On some commit's i can't see the diff - commit.diff() return empty list, but i
know what there is diff, and i can see it on site.
I can't figure out why it is happens, because on most commit's i can get a
diff.

-- 
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 5503] New: Link to TortoiseHg just redirects to the Bitbucket homepage

[mercurial-bugs]

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

Bug ID: 5503
   Summary: Link to TortoiseHg just redirects to the Bitbucket
homepage
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: website
  Assignee: bugzi...@mercurial-scm.org
  Reporter: armcorb...@gmail.com
CC: mercurial-devel@mercurial-scm.org

The Downloads page has a link for TortoiseHg that points to www.tortoisehg.org.
However, that link just redirects to the Bitbucket homepage.  

This also affects the wiki page for TortoiseHg. It has several links to
tortoisehg.bitbucket.org and that redirects to the Bitbucket homepage too.

I'm not sure what the correct URL actually is. www.tortoisehg.bitbucket.io
seems to work and was recently added to the Wikipedia article for TortoiseHg
but I can't tell if it's legitimate.

-- 
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 5504] New: hg log --encoding utf-8 -t "{join(extras,';')\n" returns non-UTF-8 characters

[mercurial-bugs]

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

Bug ID: 5504
   Summary: hg log --encoding utf-8 -t "{join(extras,';')\n"
returns non-UTF-8 characters
   Product: Mercurial
   Version: 4.1.1
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-devel@mercurial-scm.org

The log templater treats the "extras" dict of a revision as containing binary
data. Whenever there is something unprintable in it, {extras} causes such bytes
to be printed using Python string-escape syntax.

However, {join(extras,';')} (and basically anything that pushes extras through
a function) doesn't perform the same encoding, and will directly print
unencoded and unescaped bytes from the "extras" dict. As a result, hg log
--encoding X -t {join(extras,';')} may generate output that can't be decoded
using a strict decoder for X.

This makes e.g. SCM Manager (which uses a Hg command server to execute log
commands with a template that references extras) malfunction on repositories
that contain binary data in the extras field of a commit. An example of how
binary data may end up in extras appears to be hg-git.

-- 
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 5505] New: UnboundLocalError: local variable 'prompts' referenced before assignment

[mercurial-bugs]

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

Bug ID: 5505
   Summary: UnboundLocalError: local variable 'prompts' referenced
before assignment
   Product: Mercurial
   Version: 4.1.1
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: m...@michaelbaur.de
CC: mercurial-devel@mercurial-scm.org

I get this error during a large merge.

** Python 2.7.10 (default, May 23 2015, 09:44:00) [MSC v
** Mercurial Distributed SCM (version 4.1.1)
** Extensions loaded: transplant, rebase, extdiff, strip
Traceback (most recent call last):
  File "hg", line 49, in 
  File "mercurial\dispatch.pyo", line 63, in run
  File "mercurial\dispatch.pyo", line 129, in dispatch
  File "mercurial\dispatch.pyo", line 219, in _runcatch
  File "mercurial\dispatch.pyo", line 227, in callcatch
  File "mercurial\scmutil.pyo", line 152, in callcatch
  File "mercurial\dispatch.pyo", line 208, in _runcatchf
  File "mercurial\dispatch.pyo", line 811, in _dispatch
  File "mercurial\dispatch.pyo", line 563, in runcommand
  File "mercurial\extensions.pyo", line 223, in closure
  File "hgext\color.pyo", line 460, in colorcmd
  File "mercurial\dispatch.pyo", line 819, in _runcomman
  File "mercurial\dispatch.pyo", line 808, in 
  File "mercurial\util.pyo", line 1051, in check
  File "mercurial\extensions.pyo", line 223, in closure
  File "mercurial\util.pyo", line 1051, in check
  File "hgext\mq.pyo", line 3541, in mqcommand
  File "mercurial\util.pyo", line 1051, in check
  File "mercurial\commands.pyo", line 4757, in merge
  File "mercurial\hg.pyo", line 775, in merge
  File "mercurial\merge.pyo", line 1660, in update
  File "mercurial\merge.pyo", line 1301, in applyupdates
  File "mercurial\subrepo.pyo", line 265, in submerge

-- 
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 5506] New: bundle -t zstd fails on long-lived repository

[mercurial-bugs]

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

Bug ID: 5506
   Summary: bundle -t zstd fails on long-lived repository
   Product: Mercurial
   Version: 4.1.1
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: bundle2
  Assignee: bugzi...@mercurial-scm.org
  Reporter: fo...@lares.dti.ne.jp
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org

On long-lived repository (5.5 years or so, or one created with
usegeneraldelta=no, explicitly), "hg bundle --type zstd" fails
with error below.

File "/mercurial/bundle2.py", line 1320, in writebundle
  header, comp = bundletypes[bundletype]
  KeyError: 'HG10ZS'

If current repository doesn't have "generaldelta" in its
requirements, parsebundlespec() in exchange.py returns "v1" as
"appropriate bundle version".

This causes unknown bundle type name "HG10ZS" for "hg bundle
--type zstd".

This issue can be reproduced by steps below.

  $ hg --config format.usegeneraldelta=no init repo
  $ echo a > repo/a
  $ hg -R repo commit -Am '#0'
  $ hg -R repo bundle --all --type zstd bundle.zstd

-- 
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 5507] New: Merge fails with "assert sf not in data['diverge']"

[mercurial-bugs]

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

Bug ID: 5507
   Summary: Merge fails with "assert sf not in data['diverge']"
   Product: Mercurial
   Version: 4.1
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: abys...@gmail.com
CC: mercurial-devel@mercurial-scm.org

I try to merge default to my branch with:

  $ hg merge default

And I get the following stacktrace: https://bpaste.net/show/45075be0d7de

Can't produce some minimal test-case - the original repo is private.

If I disable copy trace via config, the merge is successful.

-- 
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 5508] New: Color is lost on Windows

[mercurial-bugs]

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

Bug ID: 5508
   Summary: Color is lost on Windows
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org, simon...@fb.com

Color doesn't work with pager on Windows (and didn't seem to prior to moving
both extensions into core).  However, disabling pager doesn't bring color back
either.  Bisected back to here:

changeset:   33840:3a4c0905f357
user:Simon Farnsworth 
date:Fri Feb 03 15:10:27 2017 -0800
summary: util: always force line buffered stdout when stdout is a tty (BC)

The problem is this bit in util (that was moved from pager):

if isatty(stdout):
stdout = os.fdopen(stdout.fileno(), pycompat.sysstr('wb'), 1)

I'm not sure how to triangulate between making color work, keeping Simon's time
tracking stuff working, and letting pager work.

-- 
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 5509] New: import doesn't work: "no diffs found"

[mercurial-bugs]

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

Bug ID: 5509
   Summary: import doesn't work: "no diffs found"
   Product: Mercurial
   Version: 4.1.1
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alexxx...@yandex.kz
CC: mercurial-devel@mercurial-scm.org

1. Make any changes in the repo.
2. Run hg diff > 1
3. Run hg --revert all
4. Run hg import 1 --no-commit
5. Observe the result:
applying 1
abort: 1: no diffs found

Expected result: the changes should be re-applied.

I believe the reproduction of the issue does not depend on the specific repo or
the nature of the changes made. Import simply always fails. Confirmed with
Mercurial 3.9, 4.0.1 and 4.1.1. Works fine with 3.7.3 (it always worked for as
long as I remember, since 2.x probably, only started failing recently).

-- 
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 5510] New: git diff mode ignores the -a (--text) flag, dumping out binaries instead

[mercurial-bugs]

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

Bug ID: 5510
   Summary: git diff mode ignores the -a (--text) flag, dumping
out binaries instead
   Product: Mercurial
   Version: default branch
  Hardware: Macintosh
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: simon...@fb.com
CC: mercurial-devel@mercurial-scm.org

When you ask `hg diff` to show you a diff including a binary file, you get a
"binary file changed" notice instead of a huge diff:

  $ hg init
  $ cp /bin/ls binary
  $ hg commit -Am init
  adding binary
  $ cp /bin/cp binary
  $ hg diff
  diff -r ab9f5960e788 binary
  Binary file binary has changed

If you use the --text or -a flag, you get a full diff:
  $ hg diff -a
  diff -r ab9f5960e788 binary
  --- a/binaryMon Mar 20 13:52:33 2017 +
  +++ b/binaryMon Mar 20 13:54:10 2017 +
  @@ -1,52 +1,27 @@


However, if you use the --git flag, you get a git binary diff:
  $ hg diff --git | head -n4
  diff --git a/binary b/binary
  index 
 
1bf8f59e5d36939c9c89403c68707f4943ef2183..d432d4d9f4462bbd1038bf9649a2b871578e2d48
  GIT binary patch
  literal 28912

I would expect you to need the -a flag, like git does:

  $ git diff
  index 1bf8f59..d533a9d 100755
  Binary files a/binary and b/binary differ
  $ git diff -a
  diff --git a/binary b/binary
  index d533a9d..ece1e42 100755
  --- a/binary
  +++ b/binary
  @@ -1,4024 +1,223 @@


-- 
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 5511] New: operations die with "Permission denied: .../.hg/cache/checklink-target"

[mercurial-bugs]

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

Bug ID: 5511
   Summary: operations die with "Permission denied:
.../.hg/cache/checklink-target"
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Other
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: danek.duv...@oracle.com
CC: mercurial-devel@mercurial-scm.org

If I try to run "hg stat" or "hg diff" in a repo I don't have permissions on
(which was not operated on with a new enough version of mercurial), I get

abort: Permission denied: $REPO/.hg/cache/checklink-target

Running with an older version of mercurial gives the expected results (a diff
or a list of changed fiels).

-- 
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 5512] New: The curses interface does not work on Windows.

[mercurial-bugs]

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

Bug ID: 5512
   Summary: The curses interface does not work on Windows.
   Product: Mercurial
   Version: 4.1.1
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: jeber...@free.fr
CC: mercurial-devel@mercurial-scm.org

The curses interface almost works on Windows using the package from
http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses but it fails because of a
couple of undefined signals.

Simply changing crecord.py to wrap the references to signal.SIGWINCH and
signal.SIGTSTOP inside "try: ... except: pass" blocks allows interactive commit
to work.

-- 
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 5513] New: commands.rebase.requiredest breaks `hg rebase --continue`

[mercurial-bugs]

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

Bug ID: 5513
   Summary: commands.rebase.requiredest breaks `hg rebase
--continue`
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-devel@mercurial-scm.org, r...@fb.com

Created attachment 1952
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1952&action=edit
Test that should not pass, demonstrating issue.

Using Mercurial 4.1.1+716-772878ac930e, getting into a situation where I need
to run `hg rebase --continue` fails with:

abort: you must specify a destination
(use: hg rebase -d REV)


This seems dangerous and incorrect to require (or even *allow*) for `rebase
--continue`.


Example (from the .t file, attached):

   $ hg resolve --tool internal:local --mark
+  (no more unresolved files)
+  continue: hg rebase --continue
   $ hg rebase --continue
+  abort: you must specify a destination
+  (use: hg rebase -d REV)
+  [255]

-- 
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 5514] New: commands.rebase.requiredest and commands.update.requiredest break `hg pull --rebase`

[mercurial-bugs]

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

Bug ID: 5514
   Summary: commands.rebase.requiredest and
commands.update.requiredest break `hg pull --rebase`
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-devel@mercurial-scm.org, r...@fb.com

Created attachment 1953
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1953&action=edit
Test that should not pass, demonstrating issue.

Using hg version: 4.1.1+716-772878ac930e

commands.rebase.requiredest and commands.update.requiredest break `hg pull
--rebase`:

`hg pull --rebase` does not allow one to specify a destination.  Requiring that
we specify a destination for `hg pull --rebase` doesn't really work then ;)

Both options are relevant, since if there's nothing to rebase, `hg pull
--rebase` falls back to doing an update.  

Example showing the problems are attached, but it's what you might expect: it
asks for a destination. If rebase.requiredest is on, it *always* mentions `hg
rebase -d dest`, if rebase.requiredest is off but update.requiredest is on, and
it's a rebase-less pull (so it does an update), it mentions `hg update`.

-- 
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 5515] New: zsh completion: after abbreviation 'bo' for 'bookmarks' the wrong set of completions is offered.

[mercurial-bugs]

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

Bug ID: 5515
   Summary: zsh completion: after abbreviation 'bo' for
'bookmarks' the wrong set of completions is offered.
   Product: Mercurial
   Version: 4.1.1
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: third-party
  Assignee: bugzi...@mercurial-scm.org
  Reporter: mtie...@gmx.com
CC: mercurial-devel@mercurial-scm.org

Hi, 

Summary:
I use zsh completion provided in contrib/.
A minor issue I found is when using the abbreviation 'bo' for 'bookmarks'
the set of completions offered are the 'global' ones instead of the 
'bookmarks'-specific ones.

Example:
when typing
$ hg bo --re
it completes to
$ hg bo --repository=

Instead it should offer the same completions as when using 'bookmark'
$ hg bookmark --re
 -- option --
--rename  -- rename a given bookmark
--repository  -- repository root directory
--rev -- revision

Analysis:
In
https://www.mercurial-scm.org/repo/hg-stable/file/ed5b25874d99/contrib/zsh_completion
it goes wrong in lines 96/97:
In l.96 it searches for 'bo*' from the front of the list of all command
finding 'bookmarks'.
In the condition in l.97 it compares the previously found match with the first
match starting from the back of the list of all commands ('bookmark'). The 
condition is therefore not fulfilled and the original command ('bo') is not
replaced with 'bookmarks'. This leads to the completion offering the 'normal'
completions in l.122/123. 

To me it is not obvious why the implementation uses once the first match from 
the start the list of all commands and once from the end. Using the always
the first one works for me in my daily work but I do not know enough about
Mercurial to be sure that this is the way to go.

-- 
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 5516] New: hglib doesn't reset the command server after an unexpected prompt

[mercurial-bugs]

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

Bug ID: 5516
   Summary: hglib doesn't reset the command server after an
unexpected prompt
   Product: Mercurial
   Version: 4.1.1
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: urgent
 Component: hglib
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-devel@mercurial-scm.org

When hglib encounters an unexpected prompt from the command server, it raises a
ResponseError exception. However, it fails to reset/resynchronize with the
command server. As a result, if you catch that exception, and try to run
another command, it will behave in unpredictable ways, up to and including a
hard lockup that doesn't even respond to Ctrl+C.

As an example, load the following in-process hook:
from mercurial import util

def hook(ui, repo, *args, **kwargs):
try:
repo.ui.promptchoice("dummy $$ &OK", 0)
except util.Abort:
pass

return False

as a "pre-pull" hook. Then, execute the following code:

client = hglib.open('.')
try:
client.pull()
except hglib.error.ResponseError:
pass
newtip = client.log(revrange='tip')

On my machine, this locks up in client.log inside a read(), and the command
server process itself leaks several gigabytes of memory. The only way out is to
manually kill the command server in Task Manager. It appears that hglib never
resets the command server to a "command waiting" state, and so the log command
is actually interpreted as a response to the prompt.

We should either reset the command server before raising the exception, or flag
the client as dead and deny further commands on it.

-- 
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 5517] New: `hg blame doesntexist exists` doesn't eagerly error out

[mercurial-bugs]

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

Bug ID: 5517
   Summary: `hg blame doesntexist exists` doesn't eagerly error
out
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: duri...@gmail.com
CC: mercurial-devel@mercurial-scm.org

This confuses git users. We should probably check all the filenames before
doing any blaming, and if any filename doesn't exist abort right away, so that
git users get an error message that makes sense instead of seeing blame at a
revision they don't expect. That is:

  $ hg blame deadbeef README

today prints the blame of `README` at ., then aborts because `deadbeef` isn't a
file. A git user expects that to blame `README` at revision `deadbeef`, and if
pager is on they probably don't even see the abort, which stinks.

We could even try and offer up a hint that if something looks rev-like that
maybe they want -r. I'm not sure we can sneak a "git compat" mode in for blame
here though, feels a little risky (but I'm open to being convinced on that
front).

-- 
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 5518] New: blackbox silently drops content if it does not log anything with the repo ui

[mercurial-bugs]

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

Bug ID: 5518
   Summary: blackbox silently drops content if it does not log
anything with the repo ui
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: blackbox
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arcppzju+hg...@gmail.com
CC: mercurial-devel@mercurial-scm.org

With the following config:

  $ cat >> $HGRCPATH << EOF
  > [extensions]
  > blackbox=
  > [blackbox]
  > track = commandexception
  > EOF



And a problematic extension that raises in a command:

  from mercurial import cmdutil
  cmdtable = {}
  command = cmdutil.command(cmdtable)
  @command('crash', [], 'crash')
  def crash(*args):
  raise 1

Blackbox cannot log the exception.

But if the config is changed to "track = command, commandexception", blackbox
can log the exception.

-- 
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 5519] New: mercurial-selenic.com shoud use evolve version 6.0.0

[mercurial-bugs]

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

Bug ID: 5519
   Summary: mercurial-selenic.com shoud use evolve version 6.0.0
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: infrastructure
  Assignee: bugzi...@mercurial-scm.org
  Reporter: pierre-yves.da...@ens-lyon.org
CC: kbullock+mercur...@ringworld.org,
mercurial-devel@mercurial-scm.org

This would allow us to benefit and experiment with the next discovery protocol

-- 
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 5520] New: subrepo: subrepo changes are not listed in commit template

[mercurial-bugs]

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

Bug ID: 5520
   Summary: subrepo: subrepo changes are not listed in commit
template
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arcppzju+hg...@gmail.com
CC: mercurial-devel@mercurial-scm.org

After changing a working directory parent in a subrepo, running "hg commit" in
its parent repo does not indicate subrepo changes:

  HG: Enter commit message.  Lines beginning with 'HG:' are removed.
  HG: Leave message empty to abort commit.
  HG: --
  HG: user: ...
  HG: branch 'default'
  HG: no files changed

It'll be nice if the commit template shows what subrepos are changed.

-- 
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 5521] New: kwexpand / kwshrink: want a --force option

[mercurial-bugs]

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

Bug ID: 5521
   Summary: kwexpand / kwshrink: want a --force option
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: keyword
  Assignee: bugzi...@mercurial-scm.org
  Reporter: r8yo1...@sneakemail.com
CC: blacktr...@gmx.net, mercurial-devel@mercurial-scm.org

Currently if you use kwexpand on a file and that file doesn't have unexpanded
keywords that match your expansion template, you get 'abort: outstanding
uncommitted changes'.  I'd like a way to force the expansion in that case.

example:

cat > testkw << eof
hg init foo
cd foo
echo '$KW$' > x
hg ci -Am0 x
hg --config keyword.'*'= --config extensions.hgext.keyword= --config
keywordmaps.KW='{file} {node|short} {date|utcdate} {author|user}' kwexpand x
cat x
hg --config keyword.'*'= --config extensions.hgext.keyword= --config
keywordmaps.KW='{file} {node|short} {date|utcdate} {author|user}' kwshrink x
echo '$KW manual/cruft $' > x
cat x
hg --config keyword.'*'= --config extensions.hgext.keyword= --config
keywordmaps.KW='{file} {node|short} {date|utcdate} {author|user}' kwexpand x
eof

sh -x testkw
+ hg init foo
+ cd foo
+ echo '$KW$'
+ hg ci -Am0 x
+ hg --config 'keyword.*=' --config extensions.hgext.keyword= --config
'keywordmaps.KW={file} {node|short} {date|utcdate} {author|user}' kwexpand x
+ cat x
$KW: x 946614f451c8 2017/04/04 22:33:11 jhein $
+ hg --config 'keyword.*=' --config extensions.hgext.keyword= --config
'keywordmaps.KW={file} {node|short} {date|utcdate} {author|user}' kwshrink x
+ echo '$KW manual/cruft $'
+  cat x
$KW manual/cruft $
+ hg --config 'keyword.*=' --config extensions.hgext.keyword= --config
'keywordmaps.KW={file} {node|short} {date|utcdate} {author|user}' kwexpand x
abort: outstanding uncommitted changes


I've wanted this for a while, but haven't had the chops to fashion a patch.

Does this seem like a reasonable option for keyword?

Might there be any gotchas to be wary of in the implementation of a --force?

-- 
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 5522] New: merge reports invalid nothing to merge

[mercurial-bugs]

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

Bug ID: 5522
   Summary: merge reports invalid nothing to merge
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alexraynepe...@gmail.com
CC: mercurial-devel@mercurial-scm.org

Created attachment 1954
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1954&action=edit
history with graph of point where merge fails

hallow!
i`ve try to merge into main-stream head  head, wich has an merged from
main-stream just before, and got report:
% hg merge --tool :merge --verbose 1099
прервано: nothing to merge
подсказка: use 'hg update' or check 'hg heads'
[команда вернула код 255 Wed Apr 05 11:21:42 2017]

graphicali it looks :
 <- 
   ||
   |  < merge < main>  <- 
   ||
   |+-->  < +main >
   |  --->< +main>|
   || |
if i try to merge with any other point from , before last merge point
- all ok.

i've attaches hystori graph, and some report`s

-- 
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 5523] New: renamed subrepos cause "repository X not found" warnings running hg verify

[mercurial-bugs]

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

Bug ID: 5523
   Summary: renamed subrepos cause "repository X not found"
warnings running hg verify
   Product: Mercurial
   Version: 4.0
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: mq
  Assignee: bugzi...@mercurial-scm.org
  Reporter: carandraug+...@gmail.com
CC: mercurial-devel@mercurial-scm.org

We had a subrepo on a directory named "gnulib-hg".  We now renamed it to
"gnulib".  The change of name was also done on ".hgsub" and ".hgsubstate"
files.  However, when running "hg verify", it still gives warnings about
subrepo not found.  This was not the case on hg versions 3.1.2 and 2.8.2.  It
happens now with mercurial 4.0 and 4.1.2.

Making a symlink between the old and new name, fixes the warnings.  The
revision numbers are the commits where we started to use the "gnulib-hg"
subrepo, and all the times we updated ".hgsubstate".

$ hg clone http://www.octave.org/hg/octave
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
13055 files, 23344 changesets, 155243 total revisions
checking subrepo links
15889: repository /home/carandraug/playground/octave/gnulib-hg not found
15890: repository /home/carandraug/playground/octave/gnulib-hg not found
15892: repository /home/carandraug/playground/octave/gnulib-hg not found
15905: repository /home/carandraug/playground/octave/gnulib-hg not found
16032: repository /home/carandraug/playground/octave/gnulib-hg not found
16038: repository /home/carandraug/playground/octave/gnulib-hg not found
16039: repository /home/carandraug/playground/octave/gnulib-hg not found
16081: repository /home/carandraug/playground/octave/gnulib-hg not found
16240: repository /home/carandraug/playground/octave/gnulib-hg not found
16358: repository /home/carandraug/playground/octave/gnulib-hg not found
17277: repository /home/carandraug/playground/octave/gnulib-hg not found
17840: repository /home/carandraug/playground/octave/gnulib-hg not found
19106: repository /home/carandraug/playground/octave/gnulib-hg not found
19818: repository /home/carandraug/playground/octave/gnulib-hg not found
21166: repository /home/carandraug/playground/octave/gnulib-hg not found
21479: repository /home/carandraug/playground/octave/gnulib-hg not found
21544: repository /home/carandraug/playground/octave/gnulib-hg not found
21820: repository /home/carandraug/playground/octave/gnulib-hg not found
21834: repository /home/carandraug/playground/octave/gnulib-hg not found
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
13055 files, 23344 changesets, 155243 total revisions
checking subrepo links

-- 
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 5524] New: Abort during convertion

[mercurial-bugs]

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

Bug ID: 5524
   Summary: Abort during convertion
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: convert
  Assignee: bugzi...@mercurial-scm.org
  Reporter: michaelst+mercur...@gmail.com
CC: duri...@gmail.com, mercurial-devel@mercurial-scm.org

While trying to use convert I get "abort: Argument list too long" error.
The command line I use:
hg convert --dest-type svn git_repo svn_repo

-- 
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 5525] New: New hg blame flag to show _current_ line number

[mercurial-bugs]

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

Bug ID: 5525
   Summary: New hg blame flag to show _current_ line number
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alex.gay...@gmail.com
CC: mercurial-devel@mercurial-scm.org

hg blame currently has a `-l` flag. It shows the line number _at the historical
commit_. I would like a flag to show the _current_ line number.

My use case is that I frequently identify an important line of code, I hg blame
the file to see what's up, I'd like to easily be able to identify the correct
LOC in the blame.

-- 
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 5526] New: Error trying to convert cpp-netlib git repo

[mercurial-bugs]

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

Bug ID: 5526
   Summary: Error trying to convert cpp-netlib git repo
   Product: Mercurial
   Version: 4.0.2
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: convert
  Assignee: bugzi...@mercurial-scm.org
  Reporter: visionofa...@gmail.com
CC: duri...@gmail.com, mercurial-devel@mercurial-scm.org

05-04-2017 21:30:43 arun-desk-r7 ~/code/personal/cpp$ git clone
https://github.com/carun/cpp-netlib
05-04-2017 21:30:43 arun-desk-r7 ~/code/personal/cpp$ hg convert cpp-netlib
cpp-netlib.hg
<1200+ commits>
756 Initial migration from Boost.Test to googletest
755 Merge pull request #576 from deanberris/0.12-devel-gtest-migration
754 Merged deanberris:0.12-devel-deprecations-and-refactorings and fixed
conflicts in message_test.cpp
** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.5 (default, Oct 11 2015, 17:47:16) [GCC 4.8.3 20140911 (Red Hat
4.8.3-9)]
** Mercurial Distributed SCM (version 4.0.2)
** Extensions loaded: extdiff, hgk, gpg, evolve, color, graphlog, churn, purge,
strip, mq, rebase, pager, convert, histedit, shelve, transplant, blackbox
Traceback (most recent call last):
  File "/usr/bin/hg", line 45, in 
mercurial.dispatch.run()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 60, in
run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 126, in
dispatch
ret = _runcatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 216, in
_runcatch
return callcatch(ui, _runcatchfunc)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 225, in
callcatch
return func()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 205, in
_runcatchfunc
return _dispatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 901, in
_dispatch
cmdpats, cmdoptions)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 650, in
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib64/python2.7/site-packages/mercurial/extensions.py", line 220,
in closure
return func(*(args + a), **kw)
  File "/usr/lib64/python2.7/site-packages/hgext/pager.py", line 160, in
pagecmd
return orig(ui, options, cmd, cmdfunc)
  File "/usr/lib64/python2.7/site-packages/mercurial/extensions.py", line 220,
in closure
return func(*(args + a), **kw)
  File "/usr/lib64/python2.7/site-packages/hgext/color.py", line 521, in
colorcmd
return orig(ui_, opts, cmd, cmdfunc)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 909, in
_runcommand
return cmdfunc()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 898, in

d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/lib64/python2.7/site-packages/mercurial/util.py", line 1037, in
check
return func(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/hgext/convert/__init__.py", line
391, in convert
return convcmd.convert(ui, src, dest, revmapfile, **opts)
  File "/usr/lib64/python2.7/site-packages/hgext/convert/convcmd.py", line 611,
in convert
c.convert(sortmode)
  File "/usr/lib64/python2.7/site-packages/hgext/convert/convcmd.py", line 522,
in convert
self.copy(c)
  File "/usr/lib64/python2.7/site-packages/hgext/convert/convcmd.py", line 490,
in copy
source, self.map, full, cleanp2)
  File "/usr/lib64/python2.7/site-packages/hgext/convert/hg.py", line 340, in
putcommit
node = nodemod.hex(self.repo.commitctx(ctx))
  File "/usr/lib64/python2.7/site-packages/mercurial/localrepo.py", line 105,
in wrapper
return orig(repo.unfiltered(), *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/mercurial/localrepo.py", line 1728,
in commitctx
trp, changed)
  File "/usr/lib64/python2.7/site-packages/mercurial/localrepo.py", line 1495,
in _filecommit
if fparent2 != nullid or flog.cmp(fparent1, text) or meta:
  File "/usr/lib64/python2.7/site-packages/mercurial/filelog.py", line 91, in
cmp
samehashes = not super(filelog, self).cmp(node, t)
  File "/usr/lib64/python2.7/site-packages/mercurial/revlog.py", line 1006, in
cmp
p1, p2 = self.parents(node)
  File "/usr/lib64/python2.7/site-packages/mercurial/revlog.py", line 389, in
parents
d = i[self.rev(node)]
  File "/usr/lib64/python2.7/site-packages/mercurial/revlog.py", line 362, in
rev
return self._nodecache[node]
ValueError: 20-byte hash required

-- 
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 5527] New: hg stat does not work with the pager

[mercurial-bugs]

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

Bug ID: 5527
   Summary: hg stat does not work with the pager
   Product: Mercurial
   Version: 3.9.1
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: joshg...@alum.mit.edu
CC: mercurial-devel@mercurial-scm.org

hg stat does not respect pager.attend=stat when the output is more than one
screen.

-- 
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 5528] New: commands.update.requiredest is ignored with pull --update

[mercurial-bugs]

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

Bug ID: 5528
   Summary: commands.update.requiredest is ignored with pull
--update
   Product: Mercurial
   Version: 4.1-rc
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: r...@fb.com
CC: mercurial-devel@mercurial-scm.org

Similar to issue5514, this issue is that `hg pull --update` doesn't abort as it
should when commands.update.requiredest is set to true.

See more discussion about this in #5514.

-- 
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 5529] New: Tests crash python on some versions of OS X

[mercurial-bugs]

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

Bug ID: 5529
   Summary: Tests crash python on some versions of OS X
   Product: Mercurial
   Version: default branch
  Hardware: Macintosh
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: duri...@gmail.com, mercurial-devel@mercurial-scm.org

Created attachment 1956
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1956&action=edit
crashreporter output

I'm on 10.10, with python 2.7.13 (I don't recall if it was from python.org or
via brew).  Many tests are triggering CrashReporter on this system, which I
bisected back to this:

changeset:   30576:270b077d434b
parent:  30574:1156ec81f709
user:Augie Fackler 
date:Thu Nov 10 16:07:24 2016 -0500
summary: run-tests: forward Python USER_BASE from site (issue5425)

On a clean install of 10.9.5 on another machine, there were no problems.  I
didn't get a chance to try on 10.11+.  Sample output when things went south
below (note the PyThreadState_Get() reference).  Also attached the
CrashReporter output, in case that's helpful.

MacPro64:tests atto$ ./run-tests.py --local -j16
.ss..s.s.s
--- /usr/local/mercurial/tests/test-convert-cvs.t
+++ /usr/local/mercurial/tests/test-convert-cvs.t.err
@@ -81,55 +81,29 @@
 a fixed difference from UTC.

   $ TZ=US/Hawaii hg convert --config convert.localtimezone=True src src-hg
-  initializing destination src-hg repository
-  connecting to $TESTTMP/cvsrepo
-  scanning source...
-  collecting CVS rlog
-  5 log entries
-  cvslog hook: 5 entries
-  creating changesets
-  3 changeset entries
-  cvschangesets hook: 3 changesets
-  sorting...
-  converting...
-  2 Initial revision
-  1 ci0
-  0 import
-  updating tags
+  Fatal Python error: PyThreadState_Get: no current thread
+  $TESTTMP.sh: line 80: 42151 Abort trap: 6   TZ=US/Hawaii hg convert
--config convert.localtimezone=True src src-hg
+  [134]
   $ hgcat a
-  a
-  $ hgcat b/c
-  c
-  c
+  abort: No such file or directory: 'src-hg'
+  [255]
+  $ hgcat b/c
+  abort: No such file or directory: 'src-hg'
+  [255]

 convert fresh repo with --filemap

-- 
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 5530] New: Allow bisect to accept a filtering revset

[mercurial-bugs]

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

Bug ID: 5530
   Summary: Allow bisect to accept a filtering revset
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org

In a large monolithic repository of many components, not every changeset
applies to the component being bisected.  It would be nice to be able to
specify a subset of the full range, for example with 'file(..)'.  Consider an
exaggerated case where the range is a linear 100..200, but only {100, 200} are
relevant.  That's ~6 uselessly duplicated tests.  Even if you recognize that
the test for a given changeset is redundant, skipping only moves to the next
commit instead of cutting the range in half.

A hack is to use a shell script as the command that automates the skips, and
prompts for good/bad:

filter=... # revset

match=$(hg log -r $HG_NODE -T "{ifcontains(rev, revset(\"${filter}\"), 'y')}")

if [[ $match != 'y' ]]; then
# Filtered out: skip
exit 125
fi

# prompt for good/bad/skip

The problems are the small movement for each skip, it won't work on Windows
without MSYS, and also a full checkout is done for each irrelevant version.  I
tried using --noupdate, and then updating in the script once past the skip
check. But the script must be getting called while a lock is held, as it
deadlocks.

Is this something that narrow clone also needs, or is this a case of just
saving the revset in the bisect state and applying it?

-- 
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 5531] New: `hg pull -uv` with `progress` extension produces interleaved output

[mercurial-bugs]

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

Bug ID: 5531
   Summary: `hg pull -uv` with `progress` extension produces
interleaved output
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alex.gay...@gmail.com
CC: mercurial-devel@mercurial-scm.org

This is a bit difficult to describe, so I recommend viewing the attached
screenshot.

This probably requires a large-ish pull to appear (because progress doesn't do
anything on small pulls). The mozilla-central repo pretty reliably triggers
this if I wait a day between pulls.

-- 
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 5532] New: "Interrupted system call" during `hg pull -uv` produces poor error message

[mercurial-bugs]

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

Bug ID: 5532
   Summary: "Interrupted system call" during `hg pull -uv`
produces poor error message
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alex.gay...@gmail.com
CC: mercurial-devel@mercurial-scm.org

Created attachment 1958
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1958&action=edit
Screenshot of my terminal with this issue

See the attached screenshot.

This happens to me semi-regularly during a large pull on Mozilla's
mozilla-central repo. My machine is a standard macOS, with a Journaled HFS+ FS.

-- 
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 5533] New: json encoder is too slow

[mercurial-bugs]

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

Bug ID: 5533
   Summary: json encoder is too slow
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arcppzju+hg...@gmail.com
CC: mercurial-devel@mercurial-scm.org

I wrote a simple program to compare the performance difference between stdlib
json and the json routine we have in core:

from mercurial import encoding
import contextlib
import json
import time

def hgescape(obj):
s = '{'
s += ','.join('"%s":"%s"' % (encoding.jsonescape(k),
 encoding.jsonescape(v))
  for k, v in obj.iteritems())
s += '}'
return s

@contextlib.contextmanager
def measure(name):
t1 = time.time()
yield
t2 = time.time()
print('%s: %s' % (name, t2 - t1))

lines = []
with measure('insert 50k lines'):
for l in xrange(5):
lines.append({'author': 'test',
  'commit': 'fe4713a645e44df4bbaeb8a04ea428a2d1c82a4b',
  'date': '1999-99-99'})

with measure('stdlib json escape'):
s = json.dumps(lines)

with measure('hg json escape'):
s = ','.join([hgescape(l) for l in lines])

I got something like:

insert 50k lines: 0.0199460983276
stdlib json escape: 0.0517330169678
hg json escape: 1.18240094185

So the core hg json escaping is roughly 25x slower.

That means things like "annotate -Tjson" can spend noticeable time just doing
the formatting.

I can think of two paths worth a try:

  1. Write the json encoding logic in C.
  2. Write a general purpose string-like object in C that does 2 things: `+`
 and `x.join` in a zero-copy manner. This will increase the burden of the
 GC though.

I'm not sure if there are existing libraries doing 2 already.

-- 
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 5534] New: Add subscript support to template lists

[mercurial-bugs]

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

Bug ID: 5534
   Summary: Add subscript support to template lists
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: templater
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org

It would be nice to be able to do something like this to get the last tag in
the list, when there are multiple tags on one revision:

   hg log -r . -T '{latesttag[-1]}'

That much is pretty simple, but the [] syntax cries out for dictionary support
(even though there's a get() method), and maybe list slicing with [:].

-- 
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 5535] New: [request] an option like ui.traceback, but which doesn't print on merge conflicts or keyboard interrupts

[mercurial-bugs]

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

Bug ID: 5535
   Summary: [request] an option like ui.traceback, but which
doesn't print on merge conflicts or keyboard
interrupts
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alex.gay...@gmail.com
CC: mercurial-devel@mercurial-scm.org

I'd like to have |ui.traceback| enabled so that I can file good bug reports on
intermittent issues, however it makes using mercurial frustrating, since it
also prints long tracebacks on merge conflicts and explicit keyboard
interrupts.

It'd be great to have a flag that still printed tracebacks on unexpected
exceptions, but not on exceptions which are part of the normal UX of |hg|.

-- 
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 5536] New: [request] `hg log` flag which includes the full commit message (but not the list of files)

[mercurial-bugs]

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

Bug ID: 5536
   Summary: [request] `hg log` flag which includes the full commit
message (but not the list of files)
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alex.gay...@gmail.com
CC: mercurial-devel@mercurial-scm.org

|hg log|'s --verbose flag very helpfully includes the full commit message, but
also includes the list of files changed by the commit, which I don't generally
want (and when I do want it, I use --stat).

It'd be nice to have a new flag which gives me just the full commit messages
(and then I will immediately put this flag in my [defaults]). And yes, I'm
basically trying to emulate git's behavior 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

[Bug 5537] New: email and pager interact strangely

[mercurial-bugs]

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

Bug ID: 5537
   Summary: email and pager interact strangely
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: pager
  Assignee: bugzi...@mercurial-scm.org
  Reporter: b...@serpentine.com
CC: mercurial-devel@mercurial-scm.org

Until recently, hg email -n used to run every email through a separate pager
process. This has changed, such that now all output goes through a single
invocation of the pager, and I have to carefully scan to find the boundaries of
messages instead of bouncing on the q key a few times.

It's arguably not important enough to be worth fixing, but I suspect it was an
accidental regression.

-- 
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 5538] New: followlines() spends a lot of time in linkrev adjustment

[mercurial-bugs]

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

Bug ID: 5538
   Summary: followlines() spends a lot of time in linkrev
adjustment
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gregory.sz...@gmail.com
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org

On the Firefox repo, `hg log -r 'followlines("layout/generic/nsBlockFrame.cpp",
2750:2850)'` spends ~85% of execution time in linkrev adjustment:

$ hg log -r 'followlines("layout/generic/nsBlockFrame.cpp", 2750:2850)'
--pager=false -T '{rev}\n' --profile
| 100.0%  dispatch.py:callcatchline 45: 
mercurial.dispatch.run()
| 100.0%  scmutil.py: callcatchline 234:  return
scmutil.callcatch(ui...
| 100.0%  dispatch.py:_runcatchfuncline 145:  return func()
| 100.0%  blackbox.py:log  line 215:  return
_dispatch(req)
| 99.8%  commands.py:log   line 3546:  return orig(ui,
repo, *args...
| 99.8%  cmdutil.py: getlogrevsline 3418:  revs, expr,
filematcher = c...
| 98.2%  cmdutil.py: _makelogrevsetline 2138:  expr,
filematcher = _makelo...
| 98.2%  smartset.py:__iter__  line 1961:  it = iter(revs)
| 98.2%  smartset.py:_consumegen   line 815:  for x in
self._consumegen():
| 98.2%  revset.py:   line 846:  for item in
self._gen:
| 98.2%  context.py: blockancestorsline 954:  (c.rev() for c,
_linerange
 \ 85.9%  util.py:__get__  line 763:  return
self._changeid
   | 85.9%  context.py: _changeid  line 815:  result =
self.func(obj)
   | 85.9%  context.py: _adjustlinkrev line 700:  return
self._adjustlinkrev(...
   | 85.9%  ancestor.py:__contains__   line 860:  if lkr not in
memberanc:
   | 29.0%  changelog.py:   parentrevs line 353:  for parent in
parentrevs(-h...
   |  9.7%  revlog.py:  parentrevs line 359:  return
super(changelog, sel...
 \ 12.2%  context.py: _changesrangeline 1200:  inrangep,
linerange1 = _cha...
   | 11.6%  context.py: data   line 1178:  blocks =
mdiff.allblocks(fc...
   | 11.6%  filelog.py: read   line 1132:  return
self._filelog.read(s...
   | 11.6%  revlog.py:  revision   line 48:  t =
self.revision(node)
   |  8.0%  revlog.py:  _chunksline 1313:  bins =
self._chunks(chain, ...
   |  8.0%  revlog.py:  decompress line 1232: 
ladd(decomp(buffer(data, ch...
---
Sample count: 11546
Total time: 38.47 seconds

This makes followlines() extremely slow on large repos, especially with files
with many revisions.

-- 
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 5539] New: hg prune leaves pruned tags in .hgtags

[mercurial-bugs]

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

Bug ID: 5539
   Summary: hg prune leaves pruned tags in .hgtags
   Product: Mercurial
   Version: 3.8.4
  Hardware: PC
OS: Other
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: jef...@josefsipek.net
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org

Pruning a cset which adds a tag doesn't remove the tag from .hgtags.  A
subsequent tag creation leads to multiple lines in .hgtags.

$ cat test.sh 
#!/bin/sh

set -x

rm -rf buggy
hg init buggy
cd buggy
echo a > a
hg add a
hg commit -m "added a"
hg tag v0.11
hg prune .
echo aa >> a
hg commit -m "modified a"
hg tag v0.11
cat .hgtags
hg --hidden log -G --stat
$ ./test.sh 
+ rm -rf buggy
+ hg init buggy
+ cd buggy
+ echo a
+ 1> a
+ hg add a
+ hg commit -m 'added a'
+ hg tag v0.11
+ hg prune .
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
working directory now at ccea2ef020a2
1 changesets pruned
+ echo aa
+ 1>> a
+ hg commit -m 'modified a'
+ hg tag v0.11
+ cat .hgtags
ccea2ef020a28810372574e5f5c016978e2dc5c5 v0.11
c35f92a2909e9094124073f3267c5c05070dbcf5 v0.11
+ hg --hidden log -G --stat
@  changeset:   3:72b2005a4989
|  tag: tip
|  user:Josef 'Jeff' Sipek 
|  date:Mon Apr 17 12:11:17 2017 -0400
|  summary: Added tag v0.11 for changeset c35f92a2909e
|
|   .hgtags |  2 ++
|   1 files changed, 2 insertions(+), 0 deletions(-)
|
o  changeset:   2:c35f92a2909e
|  tag: v0.11
|  parent:  0:ccea2ef020a2
|  user:Josef 'Jeff' Sipek 
|  date:Mon Apr 17 12:11:17 2017 -0400
|  summary: modified a
|
|   a |  1 +
|   1 files changed, 1 insertions(+), 0 deletions(-)
|
| x  changeset:   1:f14b117cc4bb
|/   user:Josef 'Jeff' Sipek 
|date:Mon Apr 17 12:11:16 2017 -0400
|summary: Added tag v0.11 for changeset ccea2ef020a2
|
| .hgtags |  1 +
| 1 files changed, 1 insertions(+), 0 deletions(-)
|
o  changeset:   0:ccea2ef020a2
   user:Josef 'Jeff' Sipek 
   date:Mon Apr 17 12:11:16 2017 -0400
   summary: added a

a |  1 +
1 files changed, 1 insertions(+), 0 deletions(-)

-- 
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 5540] New: Stripping a working directory parent may switch named branches

[mercurial-bugs]

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

Bug ID: 5540
   Summary: Stripping a working directory parent may switch named
branches
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: strip
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org

It's a bit surprising, given how hard `hg update` tries to stay on the current
named branch without an explicit destination.  There's no indication of the
switch in the command output (though there is an "X files
updated/merged/removed" message).  It requires a merge as part of the strip
range to trigger.  Here's an example based on the tests for 4.2-rc:

diff --git a/tests/test-strip.t b/tests/test-strip.t
--- a/tests/test-strip.t
+++ b/tests/test-strip.t
@@ -935,4 +935,97 @@
   abort: boom
   [255]

+  $ hg log -G
+  @  changeset:   1:eca11cf91c71
+  |  tag: tip
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: commitB
+  |
+  o  changeset:   0:105141ef12d0
+ user:test
+ date:Thu Jan 01 00:00:00 1970 +
+ summary: commitA
+
+  $ hg branch new-branch
+  marked working directory as branch new-branch
+  (branches are permanent and global, did you want a bookmark?)
+  $ hg ci -m "start new branch"
+  $ echo 'foo' > foo.txt
+  $ hg ci -Aqm foo
+  $ hg up default
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ echo 'bar' > bar.txt
+  $ hg ci -Aqm bar
+  $ hg up new-branch
+  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ hg merge default
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  (branch merge, don't forget to commit)
+  $ hg ci -m merge
+  $ hg log -G
+  @changeset:   5:4cf5e92caec2
+  |/   branch:  new-branch (glob)
+  | |  tag: tip
+  | |  parent:  3:f62c6c09b707
+  | |  parent:  4:35358f982181
+  | |  user:test
+  | |  date:Thu Jan 01 00:00:00 1970 +
+  | |  summary: merge
+  | |
+  | o  changeset:   4:35358f982181
+  | |  parent:  1:eca11cf91c71
+  | |  user:test
+  | |  date:Thu Jan 01 00:00:00 1970 +
+  | |  summary: bar
+  | |
+  o |  changeset:   3:f62c6c09b707
+  | |  branch:  new-branch
+  | |  user:test
+  | |  date:Thu Jan 01 00:00:00 1970 +
+  | |  summary: foo
+  | |
+  o |  changeset:   2:b1d33a8cadd9
+  |/   branch:  new-branch
+  |user:test
+  |date:Thu Jan 01 00:00:00 1970 +
+  |summary: start new branch
+  |
+  o  changeset:   1:eca11cf91c71
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: commitB
+  |
+  o  changeset:   0:105141ef12d0
+ user:test
+ date:Thu Jan 01 00:00:00 1970 +
+ summary: commitA
+
+  $ hg strip -r 35358f982181
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  saved backup bundle to
$TESTTMP\issue4736\.hg\strip-backup/35358f982181-a6f020aa-backup.hg (glob)
+  $ hg log -G
+  o  changeset:   3:f62c6c09b707
+  |  branch:  new-branch
+  |  tag: tip
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: foo
+  |
+  o  changeset:   2:b1d33a8cadd9
+  |  branch:  new-branch
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: start new branch
+  |
+  @  changeset:   1:eca11cf91c71
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: commitB
+  |
+  o  changeset:   0:105141ef12d0
+ user:test
+ date:Thu Jan 01 00:00:00 1970 +
+ summary: commitA
+


It is documented in the help, but it's not hard to read it such that --rev '.'
is part of the strip (especially if a range revset is given to the command),
and *its* most recent ancestor used.  If '.' was stripped explicitly in this
example instead, it does stay on the same branch.  (But isn't 35358f982181 "the
most recent available ancestor", per the help text?  The current behavior in
this case seems better in that it is more deterministic, in addition to staying
on the same branch.)

-- 
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 5541] New: mercurial journal extension uses incorrect sequence of fread/fwrite

[mercurial-bugs]

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

Bug ID: 5541
   Summary: mercurial journal extension uses incorrect sequence of
fread/fwrite
   Product: Mercurial
   Version: 4.1.2
  Hardware: Other
OS: Other
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: apyha...@gmail.com
CC: mercurial-devel@mercurial-scm.org

In mercurial journal extension we see the following code:

 with vfs('namejournal', mode='a+b', atomictemp=True) as f:
f.seek(0, os.SEEK_SET)
# Read just enough bytes to get a version number (up to 2
# digits plus separator)
version = f.read(3).partition('\0')[0]
if version and version != str(storageversion):
# different version of the storage. Exit early (and not
# write anything) if this is not a version we can handle or
# the file is corrupt. In future, perhaps rotate the file
# instead?
self.ui.warn(
_("unsupported journal file version '%s'\n") % version)
return
if not version:
# empty file, write version first
f.write(str(storageversion) + '\0')
f.seek(0, os.SEEK_END)
f.write(str(entry) + '\0')

It is not correct, at least for illumos, as (from fopen man page):

   When a file is opened with update mode (+ as the second or third
   character in the mode argument), both input and output may be performed
   on the associated stream. However, output must not be directly followed
   by input without an intervening call to fflush(3C) or to a file
   positioning function ( fseek(3C), fsetpos(3C) or rewind(3C)), and input
   must not be directly followed by output without an intervening call to
   a file positioning function, unless the input operation encounters end-
   of-file.

The same is stated in gnu fopen man page:

Reads and writes may be intermixed on read/write streams in any order.  Note
that ANSI C requires that a file positioning function intervene between output
and input, unless an input operation encounters  end-of-file.   (If
this  condition  is  not  met,  then a read is allowed to return the result of
writes other than the most recent.)  Therefore it is good practice (and indeed
sometimes necessary under Linux) to put an fseek(3) or fgetpos(3)
operation between write and read operations on such a stream.  This operation
may be an apparent no-op (as in fseek(..., 0L, SEEK_CUR) called for its
synchronizing side effect).

And here we see fread() folowed by fwrite(). 
This leads to missing first fwrite() result from namedjournal (leading 0 is not
recorded). 
To correct code we could use something like:

if not version:
f.seek(0, os.SEEK_SET)
# empty file, write version first
f.write(str(storageversion) + '\0')

-- 
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 5542] New: test-profile.t failure

[mercurial-bugs]

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

Bug ID: 5542
   Summary: test-profile.t failure
   Product: Mercurial
   Version: 4.1.2
  Hardware: All
OS: NetBSD
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: t...@giga.or.at
CC: mercurial-devel@mercurial-scm.org

In 4.1.2, test-profile.t started failing:

--- /scratch/devel/py-mercurial/work/mercurial-4.1.2/tests/test-profile.t
+++ /scratch/devel/py-mercurial/work/mercurial-4.1.2/tests/test-profile.t.err
@@ -90,7 +90,7 @@

   $ hg --profile --config profiling.statformat=json sleep 2>../out
   $ cat ../out
-  \[\[\d+.* (re)
+  [[-0.009995, [["/usr/pkg/lib/python2.7/threading.py", 340,
"wait"], ["/usr/pkg/lib/python2.7/threading.py", 614, "wait"],
["/usr/pkg/lib/python2.7/threading.py
", 741, "start"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/statprof.py", 312, "start"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/profiling.py", 92, "statp
rofile"], ["/usr/pkg/lib/python2.7/contextlib.py", 17, "__enter__"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/profiling.py", 148,
"profile"], ["/usr/pkg/lib/python2
.7/contextlib.py", 17, "__enter__"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/profiling.py", 173,
"maybeprofile"], ["/usr/pkg/lib/python2.7/contextlib.py", 17, "__e
nter__"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 758,
"_dispatch"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py",
208, "_runcatch
func"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/scmutil.py", 152,
"callcatch"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py",
227, "callcatch"],
 ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 219,
"_runcatch"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py",
129, "dispatch"], ["/tmp
/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 63, "run"],
["/tmp/hgtests.6XMALx/install/bin/hg", 45, ""]]],
[0.009995, [["$TESTTMP/a/sleepext
.py", 7, "sleep"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/util.py",
1051, "check"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 808, ""], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 819, 
>"_runcommand"], 
>["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 563, 
>"runcommand"]
, ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 811,
"_dispatch"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py",
208, "_runcatchfunc"], 
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/scmutil.py", 152,
"callcatch"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py",
227, "callcatch"], ["/tmp/
hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 219, "_runcatch"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 129,
"dispatch"], ["/tmp/hgtests
.6XMALx/install/lib/python/mercurial/dispatch.py", 63, "run"],
["/tmp/hgtests.6XMALx/install/bin/hg", 45, ""]]],
[0.009995, [["$TESTTMP/a/sleepext.py", 7,
 "sleep"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/util.py", 1051,
"check"], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 808,
""], ["/
tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 819,
"_runcommand"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 563,
"runcommand"], ["/tmp
/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 811, "_dispatch"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 208,
"_runcatchfunc"], ["/tmp/h
gtests.6XMALx/install/lib/python/mercurial/scmutil.py", 152, "callcatch"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 227,
"callcatch"], ["/tmp/hgtests.
6XMALx/install/lib/python/mercurial/dispatch.py", 219, "_runcatch"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 129,
"dispatch"], ["/tmp/hgtests.6XMALx/
install/lib/python/mercurial/dispatch.py", 63, "run"],
["/tmp/hgtests.6XMALx/install/bin/hg", 45, ""]]],
[0.009995, [["$TESTTMP/a/sleepext.py", 7, "sleep"
], ["/tmp/hgtests.6XMALx/install/lib/python/mercurial/util.py", 1051, "check"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 808,
""], ["/tmp/hgte
sts.6XMALx/install/lib/python/mercurial/dispatch.py", 819, "_runcommand"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 563,
"runcommand"], ["/tmp/hgtests
.6XMALx/install/lib/python/mercurial/dispatch.py", 811, "_dispatch"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 208,
"_runcatchfunc"], ["/tmp/hgtests.6
XMALx/install/lib/python/mercurial/scmutil.py", 152, "callcatch"],
["/tmp/hgtests.6XMALx/install/lib/python/mercurial/dispatch.py", 227,
"callcatch"], ["/tmp/hgtests.6XMALx/i
nstall/lib/python/mercurial/dispatch.py", 219, 

[Bug 5543] New: Bundles created with `hg bundle` don't contain hgtagsfnodes part

[mercurial-bugs]

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

Bug ID: 5543
   Summary: Bundles created with `hg bundle` don't contain
hgtagsfnodes part
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gregory.sz...@gmail.com
CC: mercurial-devel@mercurial-scm.org

0c2ded041d10 added support for transferring tags file nodes cache values as a
bundle2 part during exchange. Assuming the cache is up to date on the server,
an `hg clone` will inherit a populated cache and the first time tags are
resolved Mercurial won't have to do much work.

It appears `hg bundle` does not add this part to bundles. This means that
clones performed with clone bundles don't have a tags cache and many
client-side operations can be slow on first run until the cache data is
populated.

We should have a way for bundles produced via `hg bundle` to contain the
hgtagsfnodes bundle2 part, possibly by default.

-- 
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 5544] New: subrepo lost config options

[mercurial-bugs]

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

Bug ID: 5544
   Summary: subrepo lost config options
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arcppzju+hg...@gmail.com
CC: mercurial-devel@mercurial-scm.org

hg clone --config=extensions.lz4revlog=! repo

The "--config extensions.lz4revlog=!" flag is effective for repo, but not
effective for subrepos.

-- 
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 5545] New: histedit with interrupted merge -> empty status causes dataloss

[mercurial-bugs]

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

Bug ID: 5545
   Summary: histedit with interrupted merge -> empty status causes
dataloss
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: histedit
  Assignee: bugzi...@mercurial-scm.org
  Reporter: s...@fb.com
CC: mercurial-devel@mercurial-scm.org

Repro against ed42e00a5c4ec7a3bebaec699ef934429cdc2ddd (current @).

  $ cat >>$HGRCPATH < [extensions]
  > histedit=
  > EOF

  $ hg init foo
  $ cd foo
  $ echo one >> alpha
  $ hg addr
  adding alpha
  $ hg ci -m one
  $ echo two >> alpha
  $ hg ci -m two
  $ echo three >> alpha
  $ hg ci -m three

  $ hg log --style compact --graph
  @  2[tip]   a3884f37e029   1970-01-01 00:00 +   test
  |three
  |
  o  1   c06dfaaa4216   1970-01-01 00:00 +   test
  |two
  |
  o  0   7bed31acdb1e   1970-01-01 00:00 +   test
   one



  $ hg histedit 0 --commands - 2>&1 << EOF
  > pick 7bed31acdb1e one
  > roll a3884f37e029 three
  > roll c06dfaaa4216 two
  > EOF
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  merging alpha
  warning: conflicts while merging alpha! (edit, then use 'hg resolve --mark')
  Fix up the change (roll a3884f37e029)
  (hg histedit --continue to resume)
  [1]

  $ hg histedit --continue
  abort: unresolved merge conflicts (see 'hg help resolve')
  [255]

Make it so that 'hg status' is empty
  $ echo one > alpha
  $ hg status
  ? alpha.orig

Note we run hg histedit --continue without running hg resolve -ma
  $ hg histedit --continue
  a3884f37e029: empty changeset
  abort: outstanding merge conflicts
  [255]

Note the changeset this time is different
  $ hg histedit --continue
  c06dfaaa4216: empty changeset
  abort: outstanding merge conflicts
  [255]

Note no changeset
  $ hg histedit --continue
  abort: outstanding merge conflicts
  [255]

  $ hg resolve -ma
  (no more unresolved files)
  continue: hg histedit --continue
  $ hg histedit --continue
  saved backup bundle to
$TESTTMP/foo/.hg/strip-backup/c06dfaaa4216-ae0859b0-backup.hg (glob)

The third action got lost
  $ echo alpha
  alpha
  $ hg log --style compact --graph
  @  0[tip]   7bed31acdb1e   1970-01-01 00:00 +   test
   one

-- 
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 6214] New: inmemory rebase doesn't check for in-progress operations before starting

[mercurial-bugs]

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

Bug ID: 6214
   Summary: inmemory rebase doesn't check for in-progress
operations before starting
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: rebase
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

With rebase.experimental.inmemory=true:

hg rebase -r A -d dest -t:merge3, get a conflict. Do *not* resolve the conflict
yet.
hg rebase -r B -d dest -t:merge3, get output like the following:
rebasing 3:5d4162104fc6 "make a file baz, unrelated to foo and all that other
shenanigans" (tip)
abort: outstanding merge conflicts
(use 'hg resolve' to resolve) error about "outstanding merge conflicts".

hg rebase --continue

The `rebase --continue` will take all of the file states as they are
post-resolve (i.e. the stuff you meant to rebase when rebasing "A" above), and
instead rebase "B". So B is pruned, rebased-B that's a descendant of dest
contains all of the changes from A, and B itself is gone.

If we aren't using inmemory rebase, we get a different error message:
abort: rebase in progress
(use 'hg rebase --continue' or 'hg rebase --abort')

Other possibly relevant factors:
I'm using evolve and possibly a lot of other stuff that may have had effects
here. I'll write a .t test to reproduce the issue.

-- 
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 6215] New: Cannot file a bug for version 5.2 as it is not an option in bugzilla

[mercurial-bugs]

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

Bug ID: 6215
   Summary: Cannot file a bug for version 5.2 as it is not an
option in bugzilla
   Product: Mercurial project
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: infrastructure
  Assignee: bugzi...@mercurial-scm.org
  Reporter: rgo...@octobus.net
CC: kbullock+mercur...@ringworld.org,
mercurial-devel@mercurial-scm.org
Python Version: 2.7

-- 
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 6217] New: TypeError from `hg obslog`

[mercurial-bugs]

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

Bug ID: 6217
   Summary: TypeError from `hg obslog`
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: martinv...@google.com
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: 3.7

`hg obslog f8047a059ca0cc8c2d78f04dec347aca96db162b` fails with a traceback
that ends like this:

for mark in sorted(succmarkers[current]):
TypeError: '<' not supported between instances of 'NoneType' and 'tuple'

I think these markers are relevant:

$ hg debugobsolete | grep f8047a059ca0cc8c2d78f04dec347aca96db162b
f8047a059ca0cc8c2d78f04dec347aca96db162b 0
{00121103546ae38624861411feb6d024787f3a34} (Tue May 08 20:47:07 2012 +0200)
{'user': "'hg-dev.kraken.octopoid.net'"}
f8047a059ca0cc8c2d78f04dec347aca96db162b 0
{00121103546ae38624861411feb6d024787f3a34} (Tue May 08 20:55:23 2012 +0200)
{'user': 'Pierre-Yves David '}
f8047a059ca0cc8c2d78f04dec347aca96db162b 0
{00121103546ae38624861411feb6d024787f3a34} (Wed May 09 11:57:52 2012 +0200)
{'user': 'Pierre-Yves David '}
f8047a059ca0cc8c2d78f04dec347aca96db162b 0 (Tue May 08 20:47:07 2012 +0200)
{'user': "'hg-dev.kraken.octopoid.net'"}
f8047a059ca0cc8c2d78f04dec347aca96db162b 0 (Tue May 08 20:55:23 2012 +0200)
{'user': 'Pierre-Yves David '}
f8047a059ca0cc8c2d78f04dec347aca96db162b 0 (Wed May 09 11:57:52 2012 +0200)
{'user': 'Pierre-Yves David '}

-- 
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 6218] New: Traceback when trying to bookmark 'wdir()'

[mercurial-bugs]

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

Bug ID: 6218
   Summary: Traceback when trying to bookmark 'wdir()'
   Product: Mercurial
   Version: 5.2
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: bookmarks
  Assignee: bugzi...@mercurial-scm.org
  Reporter: z...@zash.se
CC: mercurial-devel@mercurial-scm.org
Python Version: 3.7

~$ hg debuginstall
checking encoding (UTF-8)...
checking Python executable (/usr/bin/python3)
checking Python version (3.7.3)
checking Python lib (/usr/lib/python3.7)...
checking Python security support (sni,tls1.0,tls1.1,tls1.2)
checking Mercurial version (5.2)
checking Mercurial custom build ()
checking module policy (c)
checking installed modules (/usr/lib/python3/dist-packages/mercurial)...
checking registered compression engines (bz2, bz2truncated, none, zlib, zstd)
checking available compression engines (bz2, bz2truncated, none, zlib, zstd)
checking available compression engines for wire protocol (zstd, zlib, bz2,
none)
checking "re2" regexp engine (missing)
checking templates (/usr/lib/python3/dist-packages/mercurial/templates)...
checking default template
(/usr/lib/python3/dist-packages/mercurial/templates/map-cmdline.default)
checking commit editor... (sensible-editor)
checking username...
 no username supplied
 (specify a username in your configuration file)
1 problems detected, please check your install!

~$ hg bookmark test -r 'wdir()'
** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 3.7.3 (default, Apr  3 2019, 05:39:12) [GCC 8.3.0]
** Mercurial Distributed SCM (version 5.2)
** Extensions loaded: 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mercurial/commandserver.py", line 459,
in _serverequest
sv.serve()
  File "/usr/lib/python3/dist-packages/mercurial/commandserver.py", line 363,
in serve
while self.serveone():
  File "/usr/lib/python3/dist-packages/mercurial/commandserver.py", line 337,
in serveone
handler(self)
  File "/usr/lib/python3/dist-packages/mercurial/chgserver.py", line 536, in
runcommand
return super(chgcmdserver, self).runcommand()
  File "/usr/lib/python3/dist-packages/mercurial/commandserver.py", line 321,
in runcommand
ret = dispatch.dispatch(req) & 255
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 250, in
dispatch
ret = _runcatch(req) or 0
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 424, in
_runcatch
return _callcatch(ui, _runcatchfunc)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 433, in
_callcatch
return scmutil.callcatch(ui, func)
  File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 177, in
callcatch
return func()
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 414, in
_runcatchfunc
return _dispatch(req)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1174, in
_dispatch
lui, repo, cmd, fullargs, ui, options, d, cmdpats, cmdoptions
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 862, in
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1185, in
_runcommand
return cmdfunc()
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1171, in

d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1843, in check
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/mercurial/commands.py", line 1266, in
bookmark
bookmarks.addbookmarks(repo, tr, names, rev, force, inactive)
  File "/usr/lib/python3/dist-packages/mercurial/bookmarks.py", line 986, in
addbookmarks
marks.applychanges(repo, tr, changes)
  File "/usr/lib/python3/dist-packages/mercurial/bookmarks.py", line 196, in
applychanges
self._del(name)
  File "/usr/lib/python3/dist-packages/mercurial/bookmarks.py", line 177, in
_del
node = self._refmap.pop(mark)
KeyError: b'test'

-- 
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 6219] New: mercurial can generate incomplete bundle, corrupting the repository

[mercurial-bugs]

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

Bug ID: 6219
   Summary: mercurial can generate incomplete bundle, corrupting
the repository
   Product: Mercurial
   Version: 5.2
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: pierre-yves.da...@ens-lyon.org
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

I can get Mercurial to generate a faulty bundle that corrupt a repository. I
don't know why yet. Here are the steps to reproduce:

$ hg clone -U --pull https://bitbucket.org/pypy/pypy  pypy-corruption-repro
--rev ec943df3658f --rev fe07543a0b4e
adding changesets
adding manifests
adding file changes 
added 38636 changesets with 122011 changes to 29784 files   
new changesets 45eff2219997:ec943df3658f
$ hg verify -R pypy-corruption-repro
checking changesets
checking manifests
crosschecking files in changesets and manifests 
checking files
checked 38636 changesets with 122011 changes to 29784 files 
checking subrepo links
.hgsubstate is corrupt in revision bf2c629d0071
# (the .hgsubstate error is harmless: it is just about bad content for the
file)
$ hg --cwd pypy-corruption-repro cat --rev bf2c629d0071 .hgsubstate
80037 greenlet
80037 lib_pypy/pyrepl
80037 lib_pypy/sqlite3
80037 testrunner
$ hg -R pypy-corruption-repro pull --rev fb429e4f28bd
https://bitbucket.org/pypy/pypy
pulling from https://bitbucket.org/pypy/pypy
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 0 changes to 0 files (-1 heads)
new changesets fb429e4f28bd
(run 'hg update' to get a working copy)
$ hg verify -R pypy-corruption-repro   
checking changesets
checking manifests
crosschecking files in changesets and manifests 
checking files
 .hgsubstate@38636: manifest refers to unknown revision 1a9c23c6e418
checked 38637 changesets with 122011 changes to 29784 files 
1 integrity errors encountered!
(first damaged changeset appears to be 38636)
checking subrepo links
.hgsubstate is corrupt in revision bf2c629d0071
$ hg --cwd pypy-corruption-repro cat --rev 38636 .hgsubstate
abort: data/.hgsubstate.i@1a9c23c6e418: no match found!

-- 
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 6220] New: [hg/python3] pre-tag hook can't fixup arguments anymore

[mercurial-bugs]

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

Bug ID: 6220
   Summary: [hg/python3] pre-tag hook can't fixup arguments
anymore
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: marcin.kasper...@mekk.waw.pl
CC: mercurial-devel@mercurial-scm.org
Python Version: 3.7

(background: I am porting my extensions so they work on py3 Mercurials, mostly
I succeeded but this seems to be a difficult obstacle)

It looks like py3 Mercurial's no longer allow pre-tag hook to fixup hg tag
arguments, at least some of them. My pre-tag hook changes value of b'rev'
option, on python2 it works as expected and impacts the command behaviour, on
python3 it is ignored. I suspect this is side-effect of some byteskwargs here
or there, but I am not sure.

Wider details: I faced this while porting
https://bitbucket.org/Mekk/mercurial-update_version/ to python3. This extension
solves nuisance of maintaining various VERSION constants around the code by
installing pre-tag hook which - whenever you do hg tag - extracts actual
version number from the tag, scans sources for version constants, updates those
constants, commits the change, and only then actually allows hg tag to do its
work.

In normal case (hg tag 1.2.3) it is ported and works as expected, but there is
special case of tab by revision, like
hg tag -r bf56d726edc9577b65d6063b831bd6d4c4afc98  1.2.3
The case is important as this is what TortoiseHG does under the hood when one
clicks tagging in it's interface.

I mostly give up while sb is tagging by revision, but try to do my work when
given revision matches current directory revision as then the command is
actually equivalent to hg tag 1.2.3 (and, as I said, this is what TortoiseHg
issues, so handling it is the only option to keep supporting TortoiseHg users).
But in such a case I wish to tag my version fixup commit, not the original one.

So I simply change opts[b'rev'] to None to get Mercurial tagging current
working dir repo instead of tagging bf56d726edc9577b65d6063b831bd6d4c4afc98.

Under python2 it works nicely, actual tag command uses fixed opts['rev'] and my
commit is tagged.

Under python3 it looks like my change is ignored, and original 'rev' is used
while tagging.

Tox report (all failures are caused by the test which verifies this very
behaviour, that fixed up commit is tagged, not the original one):

ERROR:   py35-hg52: commands failed
ERROR:   py35-hg51: commands failed
ERROR:   py35-hg50: commands failed
ERROR:   py36-hg52: commands failed
ERROR:   py36-hg51: commands failed
ERROR:   py36-hg50: commands failed
ERROR:   py37-hg52: commands failed
ERROR:   py37-hg51: commands failed
ERROR:   py37-hg50: commands failed
  py27-hg52: commands succeeded
  py27-hg51: commands succeeded
  py27-hg50: commands succeeded
  py27-hg49: commands succeeded
  py27-hg48: commands succeeded
  py27-hg45: commands succeeded
  py27-hg44: commands succeeded
  py27-hg41: commands succeeded
  py27-hg38: commands succeeded
  py27-hg37: commands succeeded
  py27-hg33: commands succeeded
  py27-hg30: commands succeeded
  py27-hg29: commands succeeded
  py27-hg27: commands succeeded



I suppose there can be more problems like this. In general I treat it as
breaking hook protocol in some way – pre-hooks were always able to fixup
command arguments, and this was very useful feature.

-- 
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 6221] New: pull --bookmark adds too many bookmarks

[mercurial-bugs]

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

Bug ID: 6221
   Summary: pull --bookmark adds too many bookmarks
   Product: Mercurial
   Version: 4.5.2
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: bookmarks
  Assignee: bugzi...@mercurial-scm.org
  Reporter: pe...@lucid.ch
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

"hg pull --bookmark b" should not add other bookmarks.

hg init Repo1 && hg clone Repo1 Repo2 && cd Repo1
echo a>a
hg add a && hg commit -m "A" && hg bookmark A
echo b>b
hg add b && hg commit -m "B" && hg bookmark B
cd ..\Repo2
hg pull --bookmark B

This causes:
adding remote bookmark A
adding remote bookmark B
But bookmark A is unwanted.

hg bookmarks -d A
hg pull --bookmark B

Again it is added back:
adding remote bookmark A

This even happens for bookmarks on changesets that are marked as obsolete
locally.

-- 
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 6222] New: hg pull -u does not update to the new tip after auto-evolve

[mercurial-bugs]

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

Bug ID: 6222
   Summary: hg pull -u does not update to the new tip after
auto-evolve
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arne_...@web.de
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: 2.7

When using hg pull -u with changes to evolve, the evolve is used, but the
current revision is not updated to the tip of the branch.

To reproduce, run the following script up to "TODO: bug: hg pull -u does not
update to the new tip"

https://github.com/DisyInformationssysteme/hg-ci-evolution/blob/master/test-interaction.sh

-- 
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 6223] New: graft does not respect HGMERGE

[mercurial-bugs]

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

Bug ID: 6223
   Summary: graft does not respect HGMERGE
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: arne_...@web.de
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: 2.7

When you set the mergetool in HGMERGE while having evolve activated, graft
still uses the default merge tool.

This hit me with
https://github.com/DisyInformationssysteme/hg-ci-evolution/blob/master/test-interaction.sh
(see TODO: bug: graft does not respect HGMERGE)

Without adding -t to graft, Mercurial ran meld instead of using
internal:merge-other.

Running this on another computer (right now), I cannot reproduce it, though.

-- 
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 6224] New: When window is resized, the ncurses histedit UI does not adapt

[mercurial-bugs]

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

Bug ID: 6224
   Summary: When window is resized, the ncurses histedit UI does
not adapt
   Product: Mercurial
   Version: 4.9
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: histedit
  Assignee: bugzi...@mercurial-scm.org
  Reporter: sgiese...@mozilla.com
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

When the window is resized, the ncurses histedit UI does not adapt to the new
window size. (I often run into this when I initially start hg histedit in a
very small window, which is too small to even see any lines of the commit list,
which should probably cause an error, but that is a separate issue.)

-- 
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 6225] New: phabread yields KeyError

[mercurial-bugs]

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

Bug ID: 6225
   Summary: phabread yields KeyError
   Product: Mercurial
   Version: 4.9
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: sgiese...@mozilla.com
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

Running hg phabread --stack D52876 yields the following result:

** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.17 (default, Oct 21 2019, 17:20:57) [GCC 9.2.1 20190827 (Red Hat
9.2.1-1)]
** Mercurial Distributed SCM (version 4.9)
** Extensions loaded: hgk, absorb, histedit, rebase, evolve, blackbox,
firefoxtree, js-format, push-to-try, journal, fsmonitor, share, shelve,
phabricator, clang-format
Traceback (most recent call last):
  File "/usr/bin/hg", line 43, in 
dispatch.run()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 99, in
run
status = dispatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 225, in
dispatch
ret = _runcatch(req) or 0
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 376, in
_runcatch
return _callcatch(ui, _runcatchfunc)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 384, in
_callcatch
return scmutil.callcatch(ui, func)
  File "/usr/lib64/python2.7/site-packages/mercurial/scmutil.py", line 165, in
callcatch
return func()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 367, in
_runcatchfunc
return _dispatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 1021,
in _dispatch
cmdpats, cmdoptions)
  File "/usr/lib64/python2.7/site-packages/hgext/journal.py", line 90, in
runcommand
return orig(lui, repo, cmd, fullargs, *args)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 756, in
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 1030,
in _runcommand
return cmdfunc()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 1018,
in 
d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib64/python2.7/site-packages/mercurial/util.py", line 1670, in
check
return func(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/hgext/phabricator.py", line 145, in
inner
return fn(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/hgext/phabricator.py", line 954, in
phabread
readpatch(repo, drevs, ui.write)
  File "/usr/lib64/python2.7/site-packages/hgext/phabricator.py", line 920, in
readpatch
meta = getdiffmeta(diffs[str(diffid)])
  File "/usr/lib64/python2.7/site-packages/hgext/phabricator.py", line 889, in
getdiffmeta
r'date': r'%d 0' % commit[r'time'],
KeyError: 'time'


Note that this refers to https://phabricator.services.mozilla.com/D52876

-- 
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 6226] New: terminfo color mode appears broken on Python 3

[mercurial-bugs]

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

Bug ID: 6226
   Summary: terminfo color mode appears broken on Python 3
   Product: Mercurial
   Version: default branch
  Hardware: All
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: color
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gregory.sz...@gmail.com
CC: mercurial-devel@mercurial-scm.org
Python Version: 3.7

Using Python 3.7:

```
$ hg debugcolor
warning: failed to set color mode to terminfo
ignoring unknown color/effect 'lightyellow' (configured in color.log.summary)
ignoring unknown color/effect 'lightyellow' (configured in
color.log.description)
ignoring unknown color/effect 'darkorange' (configured in color.log.tag)
ignoring unknown color/effect 'orange' (configured in color.changeset.public)
ignoring unknown color/effect 'brightyellow' (configured in
color.changeset.draft)
warning: failed to set color mode to terminfo
ignoring unknown color/effect 'lightyellow' (configured in color.log.summary)
ignoring unknown color/effect 'lightyellow' (configured in
color.log.description)
ignoring unknown color/effect 'darkorange' (configured in color.log.tag)
ignoring unknown color/effect 'orange' (configured in color.changeset.public)
ignoring unknown color/effect 'brightyellow' (configured in
color.changeset.draft)
warning: failed to set color mode to terminfo
ignoring unknown color/effect 'lightyellow' (configured in color.log.summary)
ignoring unknown color/effect 'lightyellow' (configured in
color.log.description)
ignoring unknown color/effect 'darkorange' (configured in color.log.tag)
ignoring unknown color/effect 'orange' (configured in color.changeset.public)
ignoring unknown color/effect 'brightyellow' (configured in
color.changeset.draft)
color mode: 'ansi'
available colors:
black
blue
bold
cyan
dim
green
inverse
italic
magenta
none
red
underline
white
yellow
black_background
blue_background
cyan_background
green_background
purple_background
red_background
white_background
yellow_background
```

I've briefly stepped through the color code and I suspect a str/bytes mismatch
when calling into some stdlib functions. I wouldn't be surprised if pytypes
identifies the issue pretty quickly...

-- 
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 6228] New: "/help" link for config _command_ goes to help for config _topic_

[mercurial-bugs]

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

Bug ID: 6228
   Summary: "/help" link for config _command_ goes to help for
config _topic_
   Product: Mercurial
   Version: 5.2
  Hardware: PC
   URL: https://www.mercurial-scm.org/repo/hg/help
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: hgweb
  Assignee: bugzi...@mercurial-scm.org
  Reporter: 4586274...@munyer.com
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

hgweb's "/help" page has two links named "config", one meant to be for the
configuration topic and one meant to be for the "hg config" command, but both
of those links actually go to the help page for the configuration topic.

-- 
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 6229] New: Incorrect version in hg-evolve package with Python 3

[mercurial-bugs]

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

Bug ID: 6229
   Summary: Incorrect version in hg-evolve package with Python 3
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: by...@glob.com.au
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: 3.7

Symptom: The hg-evolve package is always updated by pip even though the version
hasn't changed.

glob /opt/mercurial$ ./bin/python --version
Python 3.7.5
glob /opt/mercurial$ ./bin/pip list
PackageVersion
-- 
hg-evolve  b-9.2.1-
mercurial  5.2
pip19.3.1
setuptools 41.2.0
glob /opt/mercurial$ ./bin/pip install -U hg-evolve
Collecting hg-evolve
  Downloading
https://files.pythonhosted.org/packages/18/6c/7ae28f077dc8c9f522570e5be8a86a961bfdd47387afa1a708df034a5353/hg-evolve-9.2.1.tar.gz
(775kB)
 || 778kB 590kB/s
Installing collected packages: hg-evolve
  Found existing installation: hg-evolve b-9.2.1-
Uninstalling hg-evolve-b-9.2.1-:
  Successfully uninstalled hg-evolve-b-9.2.1-
Running setup.py install for hg-evolve ... done
Successfully installed hg-evolve-b-9.2.1-
glob /opt/mercurial$ ./bin/pip list
PackageVersion
-- 
hg-evolve  b-9.2.1-
mercurial  5.2
pip19.3.1
setuptools 41.2.0

Note hg-evolve has the version "b-9.2.1-" both prior and after running upgrade.


This is caused by get_version() in setup.py returning a byte string (b'9.2.1')
instead of a native string.

-- 
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 6230] New: Double stacktrace in evolve when pulling

[mercurial-bugs]

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

Bug ID: 6230
   Summary: Double stacktrace in evolve when pulling
   Product: Mercurial
   Version: 5.2
  Hardware: All
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: 3.7

I got this pulling onto a Mac with 5.2 from a local repo on Windows that is
being managed by py2 with thg 5.1.

(thg_pytype) Matts-Mac-mini:tests mharbison$ hg pull -r tip
http://mharbison-pc:8000
*** failed to import extension mercurial_keyring: No module named
'mercurial_keyring'
pulling from http://mharbison-pc:8000/  
searching for changes
** Unknown exception encountered with possibly-broken third-party extension
evolve
** which supports versions 5.1 of Mercurial.
** Please disable evolve and try your action again.
** If that fixes the bug please report it to https://bz.mercurial-scm.org/
** Python 3.7.4 (v3.7.4:e09359112e, Jul  8 2019, 14:54:52) [Clang 6.0
(clang-600.0.57)]
** Mercurial Distributed SCM (version 5.2)
** Extensions loaded: blackbox, eol, extdiff, lfs, purge, rebase, schemes,
share, strip, absorb, evolve, phabricator, show
Traceback (most recent call last):
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/hgext3rd/evolve/stablerangecache.py",
line 276, in _save
return self._trysave(repo)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/hgext3rd/evolve/stablerangecache.py",
line 333, in _trysave
self._saverange(con, repo)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/hgext3rd/evolve/stablerangecache.py",
line 351, in _saverange
con.executemany(_updaterange, allranges)
sqlite3.IntegrityError: UNIQUE constraint failed: range.rev, range.idx

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/mharbison/venvs/thg_pytype/bin/hg", line 36, in 
dispatch.run()
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 111, in run
status = dispatch(req)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 250, in dispatch
ret = _runcatch(req) or 0
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 424, in _runcatch
return _callcatch(ui, _runcatchfunc)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 433, in _callcatch
return scmutil.callcatch(ui, func)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/scmutil.py",
line 177, in callcatch
return func()
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 414, in _runcatchfunc
return _dispatch(req)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 1174, in _dispatch
lui, repo, cmd, fullargs, ui, options, d, cmdpats, cmdoptions
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 862, in runcommand
ret = _runcommand(ui, options, cmd, d)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 1185, in _runcommand
return cmdfunc()
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/dispatch.py",
line 1171, in 
d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/util.py",
line 1843, in check
return func(*args, **kwargs)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/util.py",
line 1843, in check
return func(*args, **kwargs)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/hgext3rd/evolve/__init__.py",
line 772, in wrapmayobsoletewc
res = origfn(ui, repo, *args, **opts)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/util.py",
line 1843, in check
return func(*args, **kwargs)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/util.py",
line 1843, in check
return func(*args, **kwargs)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/hgext/rebase.py",
line 2192, in pullrebase
ret = orig(ui, repo, *args, **opts)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/util.py",
line 1843, in check
return func(*args, **kwargs)
  File
"/Users/mharbison/venvs/thg_pytype/lib/python3.7/site-packages/mercurial/commands.py",
line 5453, in pull
opargs=pullopargs,
  File
"/Users/mharbi

[Bug 6231] New: hgtags file handled inconsistently

[mercurial-bugs]

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

Bug ID: 6231
   Summary: hgtags file handled inconsistently
   Product: Mercurial
   Version: 5.0.2
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: err...@raelity.com
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: 2.7

(I'm new to evolve, so...)
In dealing with orphans the commands
"hg evolve -r 4:" and "hg up tip; hg evolve" end up with different tag files
even though evolve is working with the same changesets in both cases.
See below for reproducible steps (can just copy to a shell). In the first case
there's a bogus entry left in the tag file, in the second the tag is lost
(known issue I think). (BTW I vote for warnings, at least in the interim...,
when dealing with draft tags)
=
hg init c2
cd c2

echo zero > zero
#echo one > one
echo two > two
echo three > three
echo five > five

hg add

hg ci -m zero zero

hg tag -r0 tagzero

hg ci -m two two
hg ci -m three three

hg tag -r 3 tagthree

hg ci -m five five

echo === hg log
hg log --template '{rev}:{node|short}  {desc|firstline}\n'

echo === hg tags
ls -l .hgtags
hg tags

echo === hg fold --exact -m 'two:three' -r 2:3
hg fold --exact -m 'two:three' -r 2:3

echo
echo NOTE: at this point hg sum shows not at tip. Is this an issue?
echo
echo === finish up

echo 
echo NOTE: \"hg up tip';'hg evolve\" and \"hg evolve -r 4:\"
echo '  produce a different .hgtags file'
echo

echo === hg evolve -r 4:
hg evolve -r 4:

#
#echo === hg update tip
#hg update tip
#echo === hg evolve
#hg evolve
#

echo === hg tags
hg tags
echo === cat .hgtags
cat .hgtags

echo
echo NOTE: tagthree is a bogus entry in the tag file

-- 
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 6232] New: please delete this bugzilla account

[mercurial-bugs]

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

Bug ID: 6232
   Summary: please delete this bugzilla account
   Product: Mercurial project
   Version: unspecified
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: infrastructure
  Assignee: bugzi...@mercurial-scm.org
  Reporter: e...@raelity.com
CC: kbullock+mercur...@ringworld.org,
mercurial-devel@mercurial-scm.org
Python Version: 2.7

I've created a new account (err...@raelity.com), consistent with my online
presence for SW dev.

-- 
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 6233] New: `hg commit --amend` can corrupt dirstate if files are modified while editor is open

[mercurial-bugs]

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

Bug ID: 6233
   Summary: `hg commit --amend` can corrupt dirstate if files are
modified while editor is open
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-devel@mercurial-scm.org
Python Version: 2.7

Basically: run `hg commit --amend`, and while the editor is open, modify one of
the files again. Save and quit the editor. There is a high likelihood (if the
file isn't new, I've reproduced this 100% of the time) that the modifications
made coincident with the editor invocation are NOT picked up, but that the
dirstate IS updated to say that they have been.


Example .t test, at 5.1.2+537-6a350194de7f, this produces:
-  OK.
+  Bug detected. 'delta' is not part of the commit OR the wdir
+  Diff and status before rebuild:
+  Diff and status after rebuild:
+  diff --git a/foo b/foo
+  --- a/foo
+  +++ b/foo
+  @@ -1,2 +1,3 @@
+   alpha
+   beta
+  +delta
+  M foo


Modifying a file while the editor is open can cause dirstate corruption

  $ hg init modify-during-amend; cd modify-during-amend
  $ echo r0 > foo; hg commit -qAm "r0"
  $ echo alpha > foo; hg commit -qm "alpha"
  $ echo beta >> foo
  $ cat > $TESTTMP/sleepy_editor < sleep 3
  > EOF
  $ chmod +x $TESTTMP/sleepy_editor
  $ HGEDITOR=$TESTTMP/sleepy_editor hg commit --amend &
  $ sleep 1
  $ echo delta >> foo
  $ sleep 3
  $ if (hg diff -c . | grep -q 'delta') || [[ -n "$(hg status)" ]]; then
  >   echo "OK."
  > else
  >   echo "Bug detected. 'delta' is not part of the commit OR the wdir"
  >   echo "Diff and status before rebuild:"
  >   hg diff
  >   hg status
  >   hg debugrebuilddirstate
  >   echo "Diff and status after rebuild:"
  >   hg diff
  >   hg status
  > fi
  OK.

-- 
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 6235] New: hg pull hglib error

[mercurial-bugs]

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

Bug ID: 6235
   Summary: hg pull hglib error
   Product: Mercurial
   Version: 5.2
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: hglib
  Assignee: bugzi...@mercurial-scm.org
  Reporter: mathias.dem...@gmail.com
CC: mercurial-devel@mercurial-scm.org
Python Version: 3.6

Traceback (most recent call last):
  File "/entrypoint", line 67, in 
sys.exit(main())
  File "/entrypoint", line 59, in main
repo.pull(source=repo_source)
  File "/usr/local/lib/python3.6/site-packages/hglib/client.py", line 1316, in
pull
self.rawcommand(args, eh=eh)
  File "/usr/local/lib/python3.6/site-packages/hglib/client.py", line 258, in
rawcommand
ret = self.runcommand(args, inchannels, outchannels)
  File "/usr/local/lib/python3.6/site-packages/hglib/client.py", line 186, in
runcommand
if any(b('\0') in a for a in args):
  File "/usr/local/lib/python3.6/site-packages/hglib/client.py", line 186, in

if any(b('\0') in a for a in args):
TypeError: 'in ' requires string as left operand, not bytes


I installed python-hglib 2.6.1, using pip in a centos:7 container.

-- 
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 6236] New: core-built msi misplaces installed files

[mercurial-bugs]

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

Bug ID: 6236
   Summary: core-built msi misplaces installed files
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: packaging
  Assignee: bugzi...@mercurial-scm.org
  Reporter: duri...@gmail.com
CC: duri...@gmail.com, mercurial-devel@mercurial-scm.org
Python Version: 2.7

Everything _works_, but I get Mercurial installed at C:\hg.exe (et al), rather
than C:\Program Files\Mercurial. I'm having trouble seeing what's wrong, but
clearly something is Very Wrong.

-- 
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 6237] New: test-clone-uncompressed.t race condition

[mercurial-bugs]

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

Bug ID: 6237
   Summary: test-clone-uncompressed.t race condition
   Product: Mercurial
   Version: 5.2rc0
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: jcris...@debian.org
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

I got a test-clone-uncompressed.t failure:

--- /<>/tests/test-clone-uncompressed.t
+++ /<>/tests/test-clone-uncompressed.t#stream-bundle2.err
@@ -404,6 +404,8 @@
   $ echo >> repo/f1
   $ echo >> repo/f2
   $ hg -R repo ci -m "1"
+  waiting for lock on repository repo held by process '31769' on host
'mipsel-aql-01/effc'
+  got lock after 1 seconds
   $ wait
   $ hg -R clone id
   

I guess that's what the "sleep 1" in there is meant to avoid, but it's not too
reliable.

Full log:
https://buildd.debian.org/status/fetch.php?pkg=mercurial&arch=mipsel&ver=5.2.1-1&stamp=1575682754&raw=0

-- 
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 6238] New: Windows: time.clock removed from python 3.8 - prevents building/running from source.

[mercurial-bugs]

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

Bug ID: 6238
   Summary: Windows: time.clock removed from python 3.8 - prevents
building/running from source.
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: tom_hin...@sil.org
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

Emits 'Unable to find a working hg binary to extract the version from the
repository tags'

Patched by checking for perf_counter (introduced in python 3.3) first:

diff -r 76d32a0edbc6 mercurial/util.py
--- a/mercurial/util.py Fri Dec 06 15:30:06 2019 +0100
+++ b/mercurial/util.py Mon Dec 09 14:48:29 2019 -0700
@@ -2040,15 +2040,17 @@
 )


+timer = None;
+if safehasattr(time, "perf_counter"):
+timer = time.perf_counter
 if pycompat.iswindows:
 checkosfilename = checkwinfilename
-timer = time.clock
+if not timer:
+timer = time.clock
 else:
 checkosfilename = platform.checkosfilename
-timer = time.time
-
-if safehasattr(time, "perf_counter"):
-timer = time.perf_counter
+if not timer:
+timer = time.time


 def makelock(info, pathname):

-- 
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 6239] New: qrefresh exclude option does not use regex

[mercurial-bugs]

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

Bug ID: 6239
   Summary: qrefresh exclude option does not use regex
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: urgent
 Component: mq
  Assignee: bugzi...@mercurial-scm.org
  Reporter: mues...@gmail.com
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

Whenever I try to exclude files with a regex it simply doesn't work at all. All
files that should be excluded are kept in the patch. Single file works though.
See the following example:

>>> touch bar.xml baz.txt foo.xml
>>> hg init
>>> hg qnew test
>>> hg qser -v
0 A test
> hg st
? bar.xml
? baz.txt
? foo.xml
>>> hg add 
Füge bar.xml hinzu
Füge baz.txt hinzu
Füge foo.xml hinzu
>>> hg qrefresh --exclude '*.xml'
>>> hg st
A bar.xml
A foo.xml
>>> hg diff
>>> hg qdiff
diff --git a/bar.xml b/bar.xml
new file mode 100644
diff --git a/baz.txt b/baz.txt
new file mode 100644
diff --git a/foo.xml b/foo.xml
new file mode 100644

The documentation clearly mentions that it expects a pattern. The version is
5.1.2 from Archlinux repo (but I also have this bug at work with CentOS).

-- 
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 6241] New: `hg phabsend -r . -r .^` creates backwards parent/child pointers

[mercurial-bugs]

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

Bug ID: 6241
   Summary: `hg phabsend -r . -r .^` creates backwards
parent/child pointers
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: martinv...@google.com
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

It seems phabsend creates the parent/child pointers in reverse order if the
revisions are given in reverse order. I think phabsend should always respect
the topology.

-- 
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 6242] New: debugupgraderepo fails due to *.i files with size of 0 bytes

[mercurial-bugs]

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

Bug ID: 6242
   Summary: debugupgraderepo fails due to *.i files with size of 0
bytes
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: stammber...@gmx.de
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

Tried to upgrade a repository to use the sparse-revlog option by adding 

[format]
sparse-revlog = yes

to the hgrc file.

Then calling
hg debugupgraderepo --run

If there exist any *.i files in .hg/store/data/... with a size of 0 bytes these
files are not copied (or converted) into the temporary repository "upgrade.and
the conversion of the repository fails with an error message something like
"The system can't find the file...".

Here the output:
-
c:\MyProject>hg debugupgraderepo --run
upgrade will perform the following actions:

requirements
   preserved: fncache, revlogv1, store
   added: dotencode, generaldelta, sparserevlog

dotencode
   repository will be better able to store files beginning with a space or
period

generaldelta
   repository storage will be able to create optimal deltas; new repository
data will be smaller and read times should decrease; interacting with other
repositories using this storage model should require less network and CPU
resources, making "hg push" and "hg pull" faster

sparserevlog
   Revlog supports delta chain with more unused data between payload. These
gaps will be skipped at read time. This allows for better delta chains, making
a better compression and faster exchange with server.

plain-cl-delta
   changelog storage will be reformated to store raw entries; changelog reading
will be faster; changelog size may be reduced

beginning upgrade...
repository locked and read-only
creating temporary repository to stage migrated data:
c:\MyProject\.hg\upgrade.p5ywyu
(it is safe to interrupt this process any time before data migration completes)
migrating 24498 total revisions (19320 in filelogs, 2588 in manifests, 2590 in
changelog)
migrating 1.59 GB in store; 27.7 GB tracked data
migrating 2850 filelogs containing 19320 revisions (1.59 GB in store; 27.4 GB
tracked data)
Transaktion abgebrochen!
Zurückrollen abgeschlossen
removing temporary repository c:\MyProject\.hg\upgrade.p5ywyu
Abbruch: Das System kann die angegebene Datei nicht finden:
'c:\MyProject\.hg\upgrade.p5ywyu\.hg/store\data/_programm/_d_e_v_i_m_a_g_e_s/_s_c_t2.jpg.i'



The file "_s_c_t2.jpg.i" has a size of 0 bytes!

-- 
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 6243] New: phabsend per repo callsign configuration

[mercurial-bugs]

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

Bug ID: 6243
   Summary: phabsend per repo callsign configuration
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Other
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: darren.mof...@oracle.com
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

The current version of phabsend provides the ability to manually configure a
single Phabricator repo callsign per user in ~/.hgrc or /.hg/hgrc of the
local copy.

When working with multiple different (and unrelated) Mercurial repos setting
callsign in ~/.hgrc doesn't work.   Setting it in /.hg/hgrc is a
workaround but still requires a manual setup for each local working copy of a
repo that a user takes.  Often our users have multiple different working copies
of a repo for different work in progress.  In our particular deployment we also
have nested Mercurial repositories as well so we would need to set
/.hg/hgrc in each of those local nested copies.

We need to either derive the callsign, like arc diff appears to be able to do,
OR there needs be be a way to set the callsign in a file that is brought into
any clones of the repo.

When using 'arc diff' the callsign can be explicitly configured for 'arc' in
.arcrc at the top of the Mercurial repository eg:
 $ arc set-config repository.callsign=ONMAN

Since /.arcrc could be a tracked file that would solve our issue if
phabsend read from arcrc.

-- 
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 6244] New: phabsend option to not create a stack

[mercurial-bugs]

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

Bug ID: 6244
   Summary: phabsend option to not create a stack
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Other
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: darren.mof...@oracle.com
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

There are sometimes cases where creating a separate view per changeset is not
desirable, regardless of wither the integration workflow is author push or a
pull.

Consider the case of multiple very small (one or two line changes) updates to
parts of a codebase that will integrate together but still benefit from being
separate changesets.  An example of this is fixing the same one or two line
error in a few different subsystems that are part of the same codebase/repo.

When creating stacked reviews it the reviewers now have to review and accept
multiple different phabricator reviews, but in this case a single review would
be more appropriate.

When using 'arc diff' the default behaviour is always a single review
containing all the changesets.

Another example is where the author is iterating on the review comments and
wants to keep the review comments as separate changesets that will be folded
together (using hg histedit) before integration.  Currently phabsend cannot be
used with this workflow at all because it ends up creating a new review for
each changeset.

This request is to have 'phabsend' allow the user to choose if a single review
or a review per-changeset should be used.

There should be a command line option --no-stack and .hgrc configuration
variable to control the behaviour so that the user can choose their default
behaviour and override it when needed.

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