Re: [PATCH] revset: introduce the summary predicate

[Yuya Nishihara]

On Fri, 6 Jan 2017 21:29:43 -0500, Matt Harbison wrote:
> > On Jan 6, 2017, at 11:19 AM, Pierre-Yves David 
> >  wrote:
> >> On 01/04/2017 07:04 PM, Matt Harbison wrote:
> >> # HG changeset patch
> >> # User Matt Harbison 
> >> # Date 1483550016 18000
> >> #  Wed Jan 04 12:13:36 2017 -0500
> >> # Node ID 76d95ab94b9e206363629059fb7824002e19a9e5
> >> # Parent  0064a1eb28e246ded9b726c696d048143d1b23f1
> >> revset: introduce the summary predicate
> >> 
> >> This is similar to the 'desc()' predicate, however the search is limited 
> >> to the
> >> first line, which I couldn't figure out how to do with the existing
> >> functionality.  Unlike 'desc()', this supports regular expressions.  The
> >> 'matching()' revset already treats the summary line distinctly from the 
> >> full
> >> description, but that finds similar revisions instead of searching with a
> >> string.
> > 
> > Looks like a great usecase to handle, I want that. However, are there 
> > reasons why:
> > 
> > 1) We could not add full pattern support to desc()
> > 2) We could not make this an extra keyworkd parameters of desc()
> > 
> > Multiplying the revset predicate hurts discoverability, having less but 
> > more powerful predicate seems useful.
> 
> I share your concern about discoverability.
> 
> I started out editing desc(), but it's explicitly documented as case 
> insensitive.  It seems confusing if matching for literals is case 
> insensitive, but regex is case sensitive for the same predicate. (I vaguely 
> recall that you can make regex case insensitive, but I think that would also 
> surprise the user.)  I meant to mention that maybe we could add pattern 
> support to desc() in addition to this, but forgot.  The other stuff I looked 
> at that supports patterns, like tag(), is case sensitive for both literals 
> and regex.  That makes sense, since those search for identifiers.

Perhaps stringmatcher can have 3 types, icase literal, literal, and re, and
the default of desc() is icase literal for backward compatibility. You can
build a case-insensitive regexp object from a literal pattern.

https://docs.python.org/2/library/re.html#re.I
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revset: introduce the summary predicate

[Matt Harbison]

> On Jan 6, 2017, at 11:19 AM, Pierre-Yves David 
>  wrote:
> 
> 
> 
>> On 01/04/2017 07:04 PM, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison 
>> # Date 1483550016 18000
>> #  Wed Jan 04 12:13:36 2017 -0500
>> # Node ID 76d95ab94b9e206363629059fb7824002e19a9e5
>> # Parent  0064a1eb28e246ded9b726c696d048143d1b23f1
>> revset: introduce the summary predicate
>> 
>> This is similar to the 'desc()' predicate, however the search is limited to 
>> the
>> first line, which I couldn't figure out how to do with the existing
>> functionality.  Unlike 'desc()', this supports regular expressions.  The
>> 'matching()' revset already treats the summary line distinctly from the full
>> description, but that finds similar revisions instead of searching with a
>> string.
> 
> Looks like a great usecase to handle, I want that. However, are there reasons 
> why:
> 
> 1) We could not add full pattern support to desc()
> 2) We could not make this an extra keyworkd parameters of desc()
> 
> Multiplying the revset predicate hurts discoverability, having less but more 
> powerful predicate seems useful.

I share your concern about discoverability.

I started out editing desc(), but it's explicitly documented as case 
insensitive.  It seems confusing if matching for literals is case insensitive, 
but regex is case sensitive for the same predicate. (I vaguely recall that you 
can make regex case insensitive, but I think that would also surprise the 
user.)  I meant to mention that maybe we could add pattern support to desc() in 
addition to this, but forgot.  The other stuff I looked at that supports 
patterns, like tag(), is case sensitive for both literals and regex.  That 
makes sense, since those search for identifiers.

I didn't consider #2, because of the issues with #1.  Can you suggest a format 
for this? I don't see any other ways to slice and dice the description, so it 
kinda feels like the recently discussed boolean arg, i.e. the equivalent of:

list get_matches(char *str, bool summary_only);

I'm not strongly opposed to this; I care more about the functionality than the 
incantation.  That said, there's been some serious bikeshedding at work about 
whether bug markers belong at the beginning or end of the summary.  The 
argument for at the beginning seems to be that it's easier to find by visually 
scanning each summary.  I'd like to push them towards the query tools, over 
eyeing things up.  Simpler and more concise will make it easier for the 
uninitiated.  Of course, I could probably create a shorter alias if needed.

> The name make perfect sense when you think about it at first contact 
> "summary" made me though about "hg summary" and I was a bit confused about 
> what this could do. I wonder if we can have something better (but questions 
> about desc seems more important first)

I can see that, but I don't have any better ideas.  I mentioned the "summary" 
field in the matching() predicate to point to prior art and consistency in the 
revset arena.

> 
>> I'm torn on whether it should support case insensitivity, like 'desc()' and
>> 'keyword()'.  It can be handy, but it seems like it would be surprising if
>> literals and regex are handled differently, or if the regex was adjusted to 
>> be
>> case insensitive internally.
>> 
>> The use case is to be able to select bug fixes out of the summary line, while
>> ignoring similar markers within the body of the commit.  I've seen previously
>> where the bug bot will erroneously update a bug that is mentioned as a
>> parenthetical within the detail of the commit message.  To illustrate on the
>> local Mercurial repo (some old markers have an internal space):
>> 
>>  $ hg log -r "desc(r' (issue')" -T "{rev}\n" | wc -l
>>  1672
>>  $ hg log -r "desc(r' (issue')" -T "{desc|firstline}\n"  \
>>  >| egrep '\(issue' | wc -l
>>  1633
>>  $ hg log -r "desc(r' (issue')" -T "{desc|firstline}\n"  \
>>  >| egrep '\(issue[0-9]+\)' | wc -l
>>  1560
>>  $ hg log -r "summary(r're: \(issue\d+\)')" -T "{rev}\n" | wc -l
>>  1560
>> 
>> I'm not sure why the splitlines() logic is that complicated, but I 
>> copy/pasted
>> from templatefilters.firstline() for consistency.
>> 
>> diff --git a/mercurial/revset.py b/mercurial/revset.py
>> --- a/mercurial/revset.py
>> +++ b/mercurial/revset.py
>> @@ -2197,6 +2197,32 @@ def subrepo(repo, subset, x):
>> 
>> return subset.filter(matches, condrepr=('', pat))
>> 
>> +@predicate('summary(string)', safe=True)
>> +def summary(repo, subset, x):
>> +"""Changesets with the given string in the summary line.  The match is 
>> case
>> +sensitive.
>> +
>> +If `value` starts with `re:`, the remainder of the value is treated as
>> +a regular expression. To match a value that actually starts with `re:`,
>> +use the prefix `literal:`.
>> +"""
>> +
>> +# i18n: "summary" is a keyword
>> +s = getstring(x, _("summary 

Re: [PATCH 2 of 8 upgraderepo V3] repair: implement requirements checking for upgrades

[Durham Goode]

On 12/24/16 12:16 PM, Augie Fackler wrote:

(+martinvonz, durham for manifest questions)

On Sun, Dec 18, 2016 at 05:07:58PM -0800, Gregory Szorc wrote:

# HG changeset patch
# User Gregory Szorc 
# Date 1482106614 28800
#  Sun Dec 18 16:16:54 2016 -0800
# Node ID 8c7cd8a43f9e9b230bc125e57b80de73eb0649b5
# Parent  94c7d28b32a1f15ebd67e4ef54114ec80b33243f
repair: implement requirements checking for upgrades

This commit introduces functionality for upgrading a repository in
place. The first part that's implemented is testing for upgrade
"compatibility." This is done by examining repository requirements.

There are 5 functions returning sets of requirements that control
upgrading. Why so many functions? Mainly to support extensions.
Functions are easier to monkeypatch than module variables.

Astute readers will see that we don't support "manifestv2" and
"treemanifest" requirements in the upgrade mechanism. I don't have
a great answer for why other than this is a complex set of patches
and I don't want to deal with the complexity of these experimental
features just yet. We can teach the upgrade mechanism about them
later, once the basic upgrade mechanism is in place.

I believe manifestv2 has turned out to be a total dead end. We should
probably jettison that code and mark the capability string as obsolete
and not to be used in the future. Does anyone see a reason for me to
not do that?
Yea, manifestv2 is dead.  Martin had asked me to kill some of the code 
during my refactor and I just never got around to it.

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

Re: [PATCH] convert: add config option to control saving Git committer in message

[Gregory Szorc]

On Fri, Jan 6, 2017 at 11:48 AM, Sean Farley  wrote:

> Gregory Szorc  writes:
>
> > On Fri, Jan 6, 2017 at 11:36 AM, Sean Farley  wrote:
> >
> >> Gregory Szorc  writes:
> >>
> >> > # HG changeset patch
> >> > # User Gregory Szorc 
> >> > # Date 1483729033 28800
> >> > #  Fri Jan 06 10:57:13 2017 -0800
> >> > # Node ID 1901566ab484a56b177b88ff080d635840e0912c
> >> > # Parent  3de9df6ee5bf7601aa3870f18304bbeb3ce351af
> >> > convert: add config option to control saving Git committer in message
> >> >
> >> > As part of converting a Git repository to Mercurial at Mozilla, I
> >> > encountered a scenario where I didn't want `hg convert` to
> >> > automatically add the "committer: " line to commit
> messages.
> >> > While I can hack around it downstream by rewriting the Git commit
> >> > before feeding it into `hg convert`, I'd prefer to just specify a
> >> > config flag to turn it off. This patch adds that flag.
> >>
> >> I'm fine with this as-is but what about maybe storing it in the
> >> metadata? Just a thought.
> >>
> >
> > I can implement that as a follow-up feature, behind yet another config
> > flag. There's a reason I put "message" in the config option :)
>
> Fair enough :-)
>

Thinking about this a little more, I suppose I can have a single option
defining a list of actions to take w.r.t. author and committer. If you feel
this is more appropriate, please drop and I'll send V2.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5460] New: AttributeError: 'module' object has no attribute 'Cmd'

[mercurial-bugs]

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

Bug ID: 5460
   Summary: AttributeError: 'module' object has no attribute 'Cmd'
   Product: Mercurial
   Version: 3.7.3
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: carballoj...@gmail.com
CC: mercurial-de...@selenic.com

When trying to pull from a repository using TortoiseHG v3.7.3 in Ubuntu 16.04,
I get the "AttributeError: 'module' object has no attribute 'Cmd'" error. I've
search a lot and it all comes down to file commands.py in Mercurial conflicting
with commands.py in Python:

/usr/lib/python2.7/commands.py
/usr/lib/python2.7/dist-packages/mercurial/commands.py

I think you need to change the name of commands.py to something more specific
to avoid conflicts. Try mercurialcommands.py.

TRACE

** Python 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]
** Mercurial Distributed SCM (version 3.7.3)
** Extensions loaded: 
Traceback (most recent call last):
  File "/usr/bin/hg", line 43, in 
mercurial.dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 54, in
run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 120, in
dispatch
ret = _runcatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 144, in
_runcatch
'pdb' : pdb.set_trace
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 130,
in __getattribute__
self._load()
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 96,
in _load
mod = _hgextimport(_import, head, globals, locals, None, level)
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 53,
in _hgextimport
return importfunc(name, globals, *args, **kwargs)
  File "/usr/lib/python2.7/pdb.py", line 59, in 
class Pdb(bdb.Bdb, cmd.Cmd):
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 131,
in __getattribute__
return getattr(self._module, attr)
AttributeError: 'module' object has no attribute 'Cmd'
cmdserver: process exited unexpectedly with code 1

PACKAGE VERSIONS

TortoiseHg
version 3.7.3
with Mercurial-3.7.3, Python-2.7.12, PyQt-4.11.4, Qt-4.8.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

Re: [PATCH] convert: add config option to control saving Git committer in message

[Sean Farley]

Gregory Szorc  writes:

> On Fri, Jan 6, 2017 at 11:36 AM, Sean Farley  wrote:
>
>> Gregory Szorc  writes:
>>
>> > # HG changeset patch
>> > # User Gregory Szorc 
>> > # Date 1483729033 28800
>> > #  Fri Jan 06 10:57:13 2017 -0800
>> > # Node ID 1901566ab484a56b177b88ff080d635840e0912c
>> > # Parent  3de9df6ee5bf7601aa3870f18304bbeb3ce351af
>> > convert: add config option to control saving Git committer in message
>> >
>> > As part of converting a Git repository to Mercurial at Mozilla, I
>> > encountered a scenario where I didn't want `hg convert` to
>> > automatically add the "committer: " line to commit messages.
>> > While I can hack around it downstream by rewriting the Git commit
>> > before feeding it into `hg convert`, I'd prefer to just specify a
>> > config flag to turn it off. This patch adds that flag.
>>
>> I'm fine with this as-is but what about maybe storing it in the
>> metadata? Just a thought.
>>
>
> I can implement that as a follow-up feature, behind yet another config
> flag. There's a reason I put "message" in the config option :)

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

Re: Picking a date for Mercurial 4.2 sprint (California, February-March)

[Martin von Zweigbergk via Mercurial-devel]

Still only 9 people signed up. The signup table on the wiki only
mentioned the weekend dates until just now, but I can't remember
deciding that we only do it on Saturday to Sunday, so it's still
presumably Friday to Sunday. The wiki is now updated accordingly, and
hopefully people's availability is still accurate now that the dates
include Friday. The people who have signed up so far are all available
March 17th-19th, so that's what I'll try to find a conference room for
now. I'll assume we'll be ~30 people.

On Thu, Dec 15, 2016 at 11:05 AM, Pierre-Yves David
 wrote:
> Hello everyone,
>
> Google is offering to host us in Mountain View, So we need to pick a
> week-end for the sprint. There is current 3 people who filled up there
> availability, we can probably expect a bigger turn around. Please update
> your availability on the wiki page so that we can choose a date for the
> sprint and start planning.
>
> https://www.mercurial-scm.org/wiki/4.2sprint
>
> Cheers,
>
> --
> Pierre-Yves David
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH RFC] patch: add index line for diff output

[Sean Farley]

Pierre-Yves David  writes:

> On 12/31/2016 10:45 PM, Sean Farley wrote:
>> # HG changeset patch
>> # User Sean Farley 
>> # Date 1483220517 21600
>> #  Sat Dec 31 15:41:57 2016 -0600
>> # Node ID e461e74f54822fef345ffb79bc806e32f03e93fe
>> # Parent  bd762c3d68423f7fa9e5e2b97425ed7108e0b8fc
>> patch: add index line for diff output
>
> TL;DR: let's make it a config option.

Sure, that's fine with me.

> It is usually recommended to include example of output change for such 
> patches.
>
> The change seems to from:
>
>  > diff --git a/mercurial/patch.py b/mercurial/patch.py
>  > --- a/mercurial/patch.py
>  > +++ b/mercurial/patch.py
>  > @@ -2499,10 +2499,19 @@ def trydiff(repo, revs, ctx1, ctx2, modi
>
> to
>
>  > diff --git a/mercurial/patch.py b/mercurial/patch.py
>  > index 376266343330..333637393631 100644
>  > --- a/mercurial/patch.py
>  > +++ b/mercurial/patch.py

Oh, good point, sorry I forgot.

>> This helps highlighting in third-party diff coloring (which assumes git
>> output). Is there any reason not to always output this as git does?
>
> Fun fact: we apparently have been doing git style diff wrong for over 
> 10- years (and yes, the doc seems to confirm the 'index' line is required).

Ha!

> I'm not very enthusiastic at the idea of updating our output to include 
> this. Part of that come from the fact we have been -not- including it 
> for the past 10 years so updating that output seems a bit bold. In 
> addition, Mercurial does not put the idea of "index" or filenode hash 
> forward much and from a user point of view I don't see too much value in 
> changing that.

Yeah, I would tend to agree here. Bit of a shame but not a big deal.

> So I would rather us to not touch the default output of 'hg diff --git'
>
>> The upside is that third-party tools don't need to change. The downside
>> is all the churn in the tests.
>
> Helping third party tool to work with Mercurial is definitely a large 
> win. In addition, being able to actually produce valid git diff seems 
> "useful".
>
> As we have a diff config section already have a [diff] section with tens 
> of config knob there I suggest we add one for this. From reading "git 
> diff" help there is a "full" variant of that index line. What about:
>
>[diff]
>extendedheader.index = [none,short,full]

Ok, that makes sense to me. There are also other headers (rename
similarity comes to mind).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] convert: add config option to control saving Git committer in message

[Gregory Szorc]

On Fri, Jan 6, 2017 at 11:36 AM, Sean Farley  wrote:

> Gregory Szorc  writes:
>
> > # HG changeset patch
> > # User Gregory Szorc 
> > # Date 1483729033 28800
> > #  Fri Jan 06 10:57:13 2017 -0800
> > # Node ID 1901566ab484a56b177b88ff080d635840e0912c
> > # Parent  3de9df6ee5bf7601aa3870f18304bbeb3ce351af
> > convert: add config option to control saving Git committer in message
> >
> > As part of converting a Git repository to Mercurial at Mozilla, I
> > encountered a scenario where I didn't want `hg convert` to
> > automatically add the "committer: " line to commit messages.
> > While I can hack around it downstream by rewriting the Git commit
> > before feeding it into `hg convert`, I'd prefer to just specify a
> > config flag to turn it off. This patch adds that flag.
>
> I'm fine with this as-is but what about maybe storing it in the
> metadata? Just a thought.
>

I can implement that as a follow-up feature, behind yet another config
flag. There's a reason I put "message" in the config option :)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] convert: add config option to control saving Git committer in message

[Sean Farley]

Gregory Szorc  writes:

> # HG changeset patch
> # User Gregory Szorc 
> # Date 1483729033 28800
> #  Fri Jan 06 10:57:13 2017 -0800
> # Node ID 1901566ab484a56b177b88ff080d635840e0912c
> # Parent  3de9df6ee5bf7601aa3870f18304bbeb3ce351af
> convert: add config option to control saving Git committer in message
>
> As part of converting a Git repository to Mercurial at Mozilla, I
> encountered a scenario where I didn't want `hg convert` to
> automatically add the "committer: " line to commit messages.
> While I can hack around it downstream by rewriting the Git commit
> before feeding it into `hg convert`, I'd prefer to just specify a
> config flag to turn it off. This patch adds that flag.

I'm fine with this as-is but what about maybe storing it in the
metadata? Just a thought.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] pager: wrap ui._runpager

[Sean Farley]

Jun Wu  writes:

> # HG changeset patch
> # User Jun Wu 
> # Date 1482711944 0
> #  Mon Dec 26 00:25:44 2016 +
> # Node ID 8e614304b040537dbc735acb6c3999a05efd258c
> # Parent  011122b3b1c42374fb0489d107418e1be3665ca6
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> 8e614304b040
> pager: wrap ui._runpager
>
> As discussed at [1], ui._runpager will be the new low-level API accepting a
> pager command to actually run the pager. And ui.pager is the high-level API
> which reads config directly from self.
>
> This change is necessary for chgserver to override _runpager cleanly.
>
> [1]: www.mercurial-scm.org/pipermail/mercurial-devel/2016-December/091656.html

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

Re: [PATCH 3 of 3] chg: check type read from S channel

[Sean Farley]

Jun Wu  writes:

> # HG changeset patch
> # User Jun Wu 
> # Date 1483719292 0
> #  Fri Jan 06 16:14:52 2017 +
> # Node ID 779b9e867ff7f6e0c0b12e700195dff97408a16d
> # Parent  703fee4099efac592f6ae1c48bfebf806dfd95bf
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> 779b9e867ff7
> chg: check type read from S channel
>
> The previous patch added the check server-side. This patch added it
> client-side.

This seems like a good and fairly straight-forward refactor to me.
Thanks!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] convert: add config option to control saving Git committer in message

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1483729033 28800
#  Fri Jan 06 10:57:13 2017 -0800
# Node ID 1901566ab484a56b177b88ff080d635840e0912c
# Parent  3de9df6ee5bf7601aa3870f18304bbeb3ce351af
convert: add config option to control saving Git committer in message

As part of converting a Git repository to Mercurial at Mozilla, I
encountered a scenario where I didn't want `hg convert` to
automatically add the "committer: " line to commit messages.
While I can hack around it downstream by rewriting the Git commit
before feeding it into `hg convert`, I'd prefer to just specify a
config flag to turn it off. This patch adds that flag.

diff --git a/hgext/convert/__init__.py b/hgext/convert/__init__.py
--- a/hgext/convert/__init__.py
+++ b/hgext/convert/__init__.py
@@ -340,6 +340,11 @@ def convert(ui, src, dest=None, revmapfi
 :convert.git.saverev: whether to store the original Git commit ID in the
 metadata of the destination commit. The default is True.
 
+:convert.git.savecommitterinmessage: whether to record the Git commit
+"committer" in the commit message if it is different from the commit
+"author." When enable, a ``committer: `` line is appended
+to the commit message as necessary. The default is True.
+
 :convert.git.skipsubmodules: does not convert root level .gitmodules files
 or files with 16 mode indicating a submodule. Default is False.
 
diff --git a/hgext/convert/git.py b/hgext/convert/git.py
--- a/hgext/convert/git.py
+++ b/hgext/convert/git.py
@@ -317,7 +317,10 @@ class convert_git(common.converter_sourc
 if n in self.copyextrakeys:
 extra[n] = v
 
-if committer and committer != author:
+committerinmessage = self.ui.configbool('convert',
+'git.savecommitterinmessage',
+True)
+if committer and committer != author and committerinmessage:
 message += "\ncommitter: %s\n" % committer
 tzs, tzh, tzm = tz[-5:-4] + "1", tz[-4:-2], tz[-2:]
 tz = -int(tzs) * (int(tzh) * 3600 + int(tzm))
diff --git a/tests/test-convert-git.t b/tests/test-convert-git.t
--- a/tests/test-convert-git.t
+++ b/tests/test-convert-git.t
@@ -482,6 +482,37 @@ convert author committer
   
   
 
+recording committer in commit message can be disabled
+
+  $ hg --config convert.git.savecommitterinmessage=false convert git-repo4 
git-repo4-hg-no-committer
+  initializing destination git-repo4-hg-no-committer repository
+  scanning source...
+  sorting...
+  converting...
+  1 addfoo
+  0 addfoo2
+  updating bookmarks
+
+  $ hg -R git-repo4-hg-no-committer log -v
+  changeset:   1:190b2da396cc
+  bookmark:master
+  tag: tip
+  user:nottest 
+  date:Mon Jan 01 00:00:21 2007 +
+  files:   foo
+  description:
+  addfoo2
+  
+  
+  changeset:   0:0735477b0224
+  user:test 
+  date:Mon Jan 01 00:00:20 2007 +
+  files:   foo
+  description:
+  addfoo
+  
+  
+
 --sourceorder should fail
 
   $ hg convert --sourcesort git-repo4 git-repo4-sourcesort-hg
diff --git a/tests/test-convert.t b/tests/test-convert.t
--- a/tests/test-convert.t
+++ b/tests/test-convert.t
@@ -282,6 +282,11 @@
   convert.git.saverev
 whether to store the original Git commit ID in the metadata
 of the destination commit. The default is True.
+  convert.git.savecommitterinmessage
+whether to record the Git commit "committer" in the commit
+message if it is different from the commit "author." When
+enable, a "committer: " line is appended to the
+commit message as necessary. The default is True.
   convert.git.skipsubmodules
 does not convert root level .gitmodules files or files with
 16 mode indicating a submodule. Default is False.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH remotenames-ext] remotenames: lazily read remotenames file

[Sean Farley]

Stanislau Hlebik  writes:

> # HG changeset patch
> # User Stanislau Hlebik 
> # Date 1483717320 28800
> #  Fri Jan 06 07:42:00 2017 -0800
> # Node ID 043090278718e0b82f6b3d8f7258d56080209d40
> # Parent  c65e41aef8dc18f29f8652f9d71a9c0d028fd95d
> remotenames: lazily read remotenames file
>
> remotenames file is read every time even if it's not needed. That wastes up
> to 100 ms on every call. Let's read it lazily instead.

Huh, I thought this was already done. Queued this one asap, thanks!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] commit: fix unmodified message detection for the "--- >8 ----" magic

[Sean Farley]

Yuya Nishihara  writes:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1483710604 -32400
> #  Fri Jan 06 22:50:04 2017 +0900
> # Node ID d19726fc559971501161eba3552f96a93a3a5c25
> # Parent  b5247f031aed69bb2f7c6a3a8d1c9b076a7384d5
> commit: fix unmodified message detection for the "--- >8 " magic
>
> We need the raw editortext to be compared with the templatetext.

Ah, really good catch. Thanks, Yuya!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 4 flagprocessor v8] revlog: flag processor

[Rémi Chaintron]

On Thu, 5 Jan 2017 at 17:50 Remi Chaintron  wrote:

> # HG changeset patch
> # User Remi Chaintron 
> # Date 1483636648 0
> #  Thu Jan 05 17:17:28 2017 +
> # Node ID 8701df1c04340e9951481dc4c366ba550b4e790f
> # Parent  a93b1ff78332f4f78e77ec9aaa2c63f7f975399c
> revlog: flag processor
>
> Add the ability for revlog objects to process revision flags and apply
> registered transforms on read/write operations.
>
> This patch introduces:
> - the 'revlog._processflags()' method that looks at revision flags and
> applies
>   flag processors registered on them. Due to the need to handle
> non-commutative
>   operations, flag transforms are applied in stable order but the order in
> which
>   the transforms are applied is reversed between read and write operations.
> - the 'addflagprocessor()' method allowing to register processors on flags.
>   Flag processors are defined as a 3-tuple of (read, write, raw) functions
> to be
>   applied depending on the operation being performed.
> - an update on 'revlog.addrevision()' behavior. The current flagprocessor
> design
>   relies on extensions to wrap around 'addrevision()' to set flags on
> revision
>   data, and on the flagprocessor to perform the actual transformation of
> its
>   contents. In the lfs case, this means we need to process flags before we
> meet
>   the 2GB size check, leading to performing some operations before it
> happens:
>   - if flags are set on the revision data, we assume some extensions might
> be
> modifying the contents using the flag processor next, and we compute
> the
> node for the original revision data (still allowing extension to
> override
> the node by wrapping around 'addrevision()').
>   - we then invoke the flag processor to apply registered transforms (in
> lfs's
> case, drastically reducing the size of large blobs).
>   - finally, we proceed with the 2GB size check.
>
> Note: In the case a cachedelta is passed to 'addrevision()' and we detect
> the
> flag processor modified the revision data, we chose to trust the flag
> processor
> and drop the cachedelta.
>
> diff --git a/mercurial/bundlerepo.py b/mercurial/bundlerepo.py
> --- a/mercurial/bundlerepo.py
> +++ b/mercurial/bundlerepo.py
> @@ -148,7 +148,10 @@
>  delta = self._chunk(chain.pop())
>  text = mdiff.patches(text, [delta])
>
> -self.checkhash(text, node, rev=rev)
> +text, validatehash = self._processflags(text, self.flags(rev),
> +'read', raw=raw)
> +if validatehash:
> +self.checkhash(text, node, rev=rev)
>  self._cache = (node, rev, text)
>  return text
>
> diff --git a/mercurial/revlog.py b/mercurial/revlog.py
> --- a/mercurial/revlog.py
> +++ b/mercurial/revlog.py
> @@ -56,6 +56,10 @@
>  REVIDX_ISCENSORED = (1 << 15) # revision has censor metadata, must be
> verified
>  REVIDX_DEFAULT_FLAGS = 0
>  REVIDX_KNOWN_FLAGS = REVIDX_ISCENSORED
> +# stable order in which flags need to be processed and their processors
> applied
> +REVIDX_FLAGS_ORDER = [
> +REVIDX_ISCENSORED,
> +]
>
>  # max size of revlog with inline data
>  _maxinline = 131072
> @@ -64,6 +68,39 @@
>  RevlogError = error.RevlogError
>  LookupError = error.LookupError
>  CensoredNodeError = error.CensoredNodeError
> +ProgrammingError = error.ProgrammingError
> +
> +# Store flag processors (cf. 'addflagprocessor()' to register)
> +_flagprocessors = { }
> +
> +def addflagprocessor(flag, processor):
> +"""Register a flag processor on a revision data flag.
> +
> +Invariant:
> +- Flags need to be defined in REVIDX_KNOWN_FLAGS and
> REVIDX_FLAGS_ORDER.
> +- Only one flag processor can be registered on a specific flag.
> +- flagprocessors must be 3-tuples of functions (read, write, raw)
> with the
> +  following signatures:
> +  - (read)  f(self, text) -> newtext, bool
> +  - (write) f(self, text) -> newtext, bool
> +  - (raw)   f(self, text) -> bool
> +  The boolean returned by these transforms is used to determine
> whether
> +  'newtext' can be used for hash integrity checking.
> +
> +  Note: The 'raw' transform is used for changegroup generation and in
> some
> +  debug commands. In this case the transform only indicates whether
> the
> +  contents can be used for hash integrity checks.
> +"""
> +if not flag & REVIDX_KNOWN_FLAGS:
> +raise ProgrammingError(_(
> +"cannot register processor on unknown flag '%x'." % (flag)))
> +if flag not in REVIDX_FLAGS_ORDER:
> +raise ProgrammingError(_(
> +"flag '%x' undefined in REVIDX_FLAGS_ORDER." % (flag)))
> +if flag in _flagprocessors:
> +raise error.Abort(_(
> +"cannot register multiple processors on flag '%x'." % (flag)))
> +_flagprocessors[flag] = processor
>
>  def getoffset(q):
>  return int(q >> 16)
> @@ -1231,11 +1268,6 @@
>  if rev 

Re: [PATCH evolve-ext] fold: disallow multiple revisions without --exact

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jan 6, 2017 at 7:12 AM, Pierre-Yves David
 wrote:
>
>
> On 01/04/2017 10:47 PM, Martin von Zweigbergk wrote:
>>
>> On Wed, Jan 4, 2017 at 11:40 AM, Pierre-Yves David
>>  wrote:
>>>
>>> On 01/04/2017 05:38 PM, Martin von Zweigbergk wrote:

 On Wed, Jan 4, 2017 at 4:53 AM, Pierre-Yves David
  wrote:
>
> On 12/18/2016 06:36 PM, Martin von Zweigbergk via Mercurial-devel
> wrote:
>>
>> On Fri, Dec 16, 2016, 23:53 Pierre-Yves David
>> > >
>> wrote:
>> On 11/05/2016 12:58 AM, Martin von Zweigbergk via Mercurial-devel
>> wrote:
>> > # HG changeset patch
>> > # User Martin von Zweigbergk > >
>> > # Date 1478303512 25200
>> > #  Fri Nov 04 16:51:52 2016 -0700
>> > # Node ID bb80851fe9a6e14263f0076074108556377141f9
>> > # Parent  cb2bac3253fbd52894ffcb4719a148fe6a3da38b
>> > fold: disallow multiple revisions without --exact
>
> […]
>
>
> Currently I would weight "constraint" that way
> (more important to least important):
>
>  (1) no revset knowledge required:
>  simplicity is very important,


 That makes sense, but note that "hg fold -r foo -r bar" is already
 supported and does not require the user to know about revsets (and one
 can also drop the "-r"s in that command). I feel like you're assuming
 that defaulting to --exact requires the user to know about revsets. I
 don't see it that way.
>>>
>>>
>>> The "specify multiple revs" approach "works" but is quickly cumbersome
>>> and
>>> error prone if you have more than a couple changesets.
>>>
>>> There is currently two others tools that someone can use to fold
>>> changesets:
>>>  * hg rebase --collapse
>>>  * hg histedit
>>> Both provide the user with a simple way to fold many changesets (eg: by
>>> providing a root). So a kind of bottom line here is that it would be
>>> really
>>> awkward if the command dedicated to folding changeset end up being less
>>> user
>>> friendly than command dedicated to other usecase (that happen to be able
>>> to
>>> fold things as a secondary feature).
>>>
>>> This made me implicitly discard the option to "list every single
>>> changeset
>>> to be folded" from the "viable UI" list.  Thanks for pointing this out.
>>> It
>>> gave me the chance to unearth that extra criteria: "be a better UI than
>>> the
>>> existing solution".
>>>
>>> What do you think ?
>>
>>
>> Thanks for mentioning rebase. Rebase has various ways of specifying
>> which revisions to rebase (-b,-s,-r). It also has a default, which I
>> consider a mistake.
>
>
> Actually, rebase has two defaults:
>
> - The default destination:
> It used to be pretty bad, working only in the simplest case and being
> harmful in all the others. However, this actually got fixed last year and it
> now pretty okay. It even has the potential to become pretty awesome once we
> have a good story regarding feature branches and names. See associated wiki
> page for details:
> https://www.mercurial-scm.org/wiki/DefaultDestinationPlan

This is the one I was referring to. I'm happy with the default rebase set.

>
> - The default rebase set: (-b .)
> It seems to fit the needs in most case and I don't think I've seen much
> complains about it. We can probably improve that a bit when we get a good
> "current working set" story through feature branch.
>
> I agree that bad default are mistake, but good default are great and have
> been a good advantage of Mercurial. We should keep aiming at good default
> whenever we can.

Oh, definitely. I liked git's default destination and relied on it all
the time. See 
https://github.com/git/git/commit/15a147e61898d25ec8b539190e87f3a09592c9c8
:-)

>
>> So, how about making "hg fold" not have a default?
>> I suggest we ask the user to say either "hg fold --from=$rev" to get
>> the behavior they currently get by default, and "hg fold -r $revset"
>> (or "hg fold -r $rev1 -r $rev2" for beginners). Note that I'm
>> suggesting that --exact will not be needed (and can be deprecated),
>> because I don't like to have the argument passed to -r be used for
>> different things based on that flag. How does that sound?
>
>
> The --from things is to consider, it seems to match our current constraint
> including the one about not being worse than the existing solution (It does
> not strike me as much better, but at least not worse). Not sure about the
> word since we might want to allow it to specify descendant too (not just
> ancestors).

We could also add a --to, but that seems like something that would be
used very rarely. Leave it out for now?

>
> I'm not sure what you mean with the --rev flag. Do you mean that default
> entry would be revset? Or 

[PATCH] run-tests: unset CHGDEBUG

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1483719581 0
#  Fri Jan 06 16:19:41 2017 +
# Node ID 50ad6dbc71c76ab1a9e684b59720d8fa7fbd6797
# Parent  011122b3b1c42374fb0489d107418e1be3665ca6
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 50ad6dbc71c7
run-tests: unset CHGDEBUG

With CHGDEBUG, chg outputs much more stuff and the test could fail running
with --chg. So unset the environment variable.

diff --git a/tests/run-tests.py b/tests/run-tests.py
--- a/tests/run-tests.py
+++ b/tests/run-tests.py
@@ -850,5 +850,5 @@ class Test(unittest.TestCase):
 
 for k in ('HG HGPROF CDPATH GREP_OPTIONS http_proxy no_proxy ' +
-  'NO_PROXY').split():
+  'NO_PROXY CHGDEBUG').split():
 if k in env:
 del env[k]
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revset: introduce the summary predicate

[Pierre-Yves David]

On 01/04/2017 07:04 PM, Matt Harbison wrote:

# HG changeset patch
# User Matt Harbison 
# Date 1483550016 18000
#  Wed Jan 04 12:13:36 2017 -0500
# Node ID 76d95ab94b9e206363629059fb7824002e19a9e5
# Parent  0064a1eb28e246ded9b726c696d048143d1b23f1
revset: introduce the summary predicate

This is similar to the 'desc()' predicate, however the search is limited to the
first line, which I couldn't figure out how to do with the existing
functionality.  Unlike 'desc()', this supports regular expressions.  The
'matching()' revset already treats the summary line distinctly from the full
description, but that finds similar revisions instead of searching with a
string.


Looks like a great usecase to handle, I want that. However, are there 
reasons why:


1) We could not add full pattern support to desc()
2) We could not make this an extra keyworkd parameters of desc()

Multiplying the revset predicate hurts discoverability, having less but 
more powerful predicate seems useful.


The name make perfect sense when you think about it at first contact 
"summary" made me though about "hg summary" and I was a bit confused 
about what this could do. I wonder if we can have something better (but 
questions about desc seems more important first)




I'm torn on whether it should support case insensitivity, like 'desc()' and
'keyword()'.  It can be handy, but it seems like it would be surprising if
literals and regex are handled differently, or if the regex was adjusted to be
case insensitive internally.

The use case is to be able to select bug fixes out of the summary line, while
ignoring similar markers within the body of the commit.  I've seen previously
where the bug bot will erroneously update a bug that is mentioned as a
parenthetical within the detail of the commit message.  To illustrate on the
local Mercurial repo (some old markers have an internal space):

  $ hg log -r "desc(r' (issue')" -T "{rev}\n" | wc -l
  1672
  $ hg log -r "desc(r' (issue')" -T "{desc|firstline}\n"  \
  >| egrep '\(issue' | wc -l
  1633
  $ hg log -r "desc(r' (issue')" -T "{desc|firstline}\n"  \
  >| egrep '\(issue[0-9]+\)' | wc -l
  1560
  $ hg log -r "summary(r're: \(issue\d+\)')" -T "{rev}\n" | wc -l
  1560

I'm not sure why the splitlines() logic is that complicated, but I copy/pasted
from templatefilters.firstline() for consistency.

diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -2197,6 +2197,32 @@ def subrepo(repo, subset, x):

 return subset.filter(matches, condrepr=('', pat))

+@predicate('summary(string)', safe=True)
+def summary(repo, subset, x):
+"""Changesets with the given string in the summary line.  The match is case
+sensitive.
+
+If `value` starts with `re:`, the remainder of the value is treated as
+a regular expression. To match a value that actually starts with `re:`,
+use the prefix `literal:`.
+"""
+
+# i18n: "summary" is a keyword
+s = getstring(x, _("summary requires a string"))
+kind, value, matcher = _substringmatcher(s)
+
+def _matchvalue(r):
+_desc = repo[r].description()
+_sum = ''
+try:
+_sum = _desc.splitlines(True)[0].rstrip('\r\n')
+except IndexError:
+pass
+
+return matcher(_sum)
+
+return subset.filter(lambda r: _matchvalue(r), condrepr=('', 
s))
+
 def _substringmatcher(pattern):
 kind, pattern, matcher = util.stringmatcher(pattern)
 if kind == 'literal':
diff --git a/tests/test-commit.t b/tests/test-commit.t
--- a/tests/test-commit.t
+++ b/tests/test-commit.t
@@ -252,13 +252,50 @@ full log
   commit-foo-subdir


+  $ cat > ../commit-log-test < issue fix (bug1234)
+  >
+  > multiline description here
+  > EOF
+  $ echo "edited" >> foo/plain-file
+  $ hg ci -l ../commit-log-test
+
+Summary doesn't search past the first line
+  $ hg log -r "summary('description')"
+
+Summary works with regex
+  $ hg log -r "summary(r're:\(bug\d+\)')"
+  changeset:   2:5364ddbe8265
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: issue fix (bug1234)
+
+
+Summary works with partial matches
+  $ hg log -r "summary('foo')"
+  changeset:   0:65d4e9386227
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: commit-foo-subdir
+
+  changeset:   1:95b38e3a5b2e
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: commit-foo-dot
+

 subdir log

   $ cd foo
   $ hg log .
+  changeset:   2:5364ddbe8265
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: issue fix (bug1234)
+
   changeset:   1:95b38e3a5b2e
-  tag: tip
   user:test
   date:Thu Jan 01 00:00:00 1970 +
   summary: commit-foo-dot
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org

[PATCH 1 of 3] chg: send type information via S channel (BC)

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1483719063 0
#  Fri Jan 06 16:11:03 2017 +
# Node ID 530b32a20c085fd9819bad3235ffbca5f98095ea
# Parent  011122b3b1c42374fb0489d107418e1be3665ca6
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 530b32a20c08
chg: send type information via S channel (BC)

Previously S channel is only used to send system commands. It will also be
used to send pager commands. So add a type parameter.

This breaks older chg clients. But chg and hg should always come from a
single commit and be packed into a single package. Supporting running
inconsistent versions of chg and hg seems to be unnecessarily complicated
with little benefit. So just make the change and assume people won't use
inconsistent chg with hg.

diff --git a/contrib/chg/hgclient.c b/contrib/chg/hgclient.c
--- a/contrib/chg/hgclient.c
+++ b/contrib/chg/hgclient.c
@@ -238,8 +238,8 @@ static void handlesystemrequest(hgclient
 
const char **args = unpackcmdargsnul(ctx);
-   if (!args[0] || !args[1])
-   abortmsg("missing command or cwd in system request");
-   debugmsg("run '%s' at '%s'", args[0], args[1]);
-   int32_t r = runshellcmd(args[0], args + 2, args[1]);
+   if (!args[0] || !args[1] || !args[2])
+   abortmsg("missing type or command or cwd in system request");
+   debugmsg("run '%s' at '%s'", args[1], args[2]);
+   int32_t r = runshellcmd(args[1], args + 3, args[2]);
free(args);
 
diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py
--- a/mercurial/chgserver.py
+++ b/mercurial/chgserver.py
@@ -288,4 +288,5 @@ class channeledsystem(object):
 
 payload length (unsigned int),
+type, '\0',
 cmd, '\0',
 cwd, '\0',
@@ -294,5 +295,5 @@ class channeledsystem(object):
 envkey, '=', val
 
-and waits:
+if type == 'system', waits for:
 
 exitcode length (unsigned int),
@@ -304,6 +305,6 @@ class channeledsystem(object):
 self.channel = channel
 
-def __call__(self, cmd, environ, cwd):
-args = [util.quotecommand(cmd), os.path.abspath(cwd or '.')]
+def __call__(self, cmd, environ, cwd, type='system'):
+args = [type, util.quotecommand(cmd), os.path.abspath(cwd or '.')]
 args.extend('%s=%s' % (k, v) for k, v in environ.iteritems())
 data = '\0'.join(args)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3] chg: check type read from S channel

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1483719292 0
#  Fri Jan 06 16:14:52 2017 +
# Node ID 779b9e867ff7f6e0c0b12e700195dff97408a16d
# Parent  703fee4099efac592f6ae1c48bfebf806dfd95bf
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 779b9e867ff7
chg: check type read from S channel

The previous patch added the check server-side. This patch added it
client-side.

diff --git a/contrib/chg/hgclient.c b/contrib/chg/hgclient.c
--- a/contrib/chg/hgclient.c
+++ b/contrib/chg/hgclient.c
@@ -240,12 +240,16 @@ static void handlesystemrequest(hgclient
if (!args[0] || !args[1] || !args[2])
abortmsg("missing type or command or cwd in system request");
-   debugmsg("run '%s' at '%s'", args[1], args[2]);
-   int32_t r = runshellcmd(args[1], args + 3, args[2]);
-   free(args);
+   if (strcmp(args[0], "system") == 0) {
+   debugmsg("run '%s' at '%s'", args[1], args[2]);
+   int32_t r = runshellcmd(args[1], args + 3, args[2]);
+   free(args);
 
-   uint32_t r_n = htonl(r);
-   memcpy(ctx->data, _n, sizeof(r_n));
-   ctx->datasize = sizeof(r_n);
-   writeblock(hgc);
+   uint32_t r_n = htonl(r);
+   memcpy(ctx->data, _n, sizeof(r_n));
+   ctx->datasize = sizeof(r_n);
+   writeblock(hgc);
+   } else {
+   abortmsg("unknown type in system request: %s", args[0]);
+   }
 }
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 3] chgserver: check type passed to S channel

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1483719145 0
#  Fri Jan 06 16:12:25 2017 +
# Node ID 703fee4099efac592f6ae1c48bfebf806dfd95bf
# Parent  530b32a20c085fd9819bad3235ffbca5f98095ea
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 703fee4099ef
chgserver: check type passed to S channel

It currently only supports the "system" type. Add an explicit check.

diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py
--- a/mercurial/chgserver.py
+++ b/mercurial/chgserver.py
@@ -313,10 +313,13 @@ class channeledsystem(object):
 self.out.flush()
 
-length = self.in_.read(4)
-length, = struct.unpack('>I', length)
-if length != 4:
-raise error.Abort(_('invalid response'))
-rc, = struct.unpack('>i', self.in_.read(4))
-return rc
+if type == 'system':
+length = self.in_.read(4)
+length, = struct.unpack('>I', length)
+if length != 4:
+raise error.Abort(_('invalid response'))
+rc, = struct.unpack('>i', self.in_.read(4))
+return rc
+else:
+raise error.ProgrammingError('invalid S channel type: %s' % type)
 
 _iochannels = [
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 6 of 6 V5] summary: add evolution "troubles" information to summary output

[Pierre-Yves David]

On 01/06/2017 04:32 PM, Denis Laxalde wrote:

# HG changeset patch
# User Denis Laxalde 
# Date 1483709722 -3600
#  Fri Jan 06 14:35:22 2017 +0100
# Node ID 3a382f7173808665968de416db145ade8c56672c
# Parent  1d9bdfeb0afded737513f51e75cefa11e9231fdf
# EXP-Topic evolve-ui
summary: add evolution "troubles" information to summary output


That series seems fine and is pushed. Thanks for the various fixes/cleanup.

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

[PATCH remotenames-ext] remotenames: lazily read remotenames file

[Stanislau Hlebik]

# HG changeset patch
# User Stanislau Hlebik 
# Date 1483717320 28800
#  Fri Jan 06 07:42:00 2017 -0800
# Node ID 043090278718e0b82f6b3d8f7258d56080209d40
# Parent  c65e41aef8dc18f29f8652f9d71a9c0d028fd95d
remotenames: lazily read remotenames file

remotenames file is read every time even if it's not needed. That wastes up
to 100 ms on every call. Let's read it lazily instead.

diff --git a/remotenames.py b/remotenames.py
--- a/remotenames.py
+++ b/remotenames.py
@@ -282,7 +282,7 @@
 """Read-only dict-like Class to lazily resolve remotename entries
 
 We are doing that because remotenames startup was slow.
-We read the remotenames file once to figure out the potential entries
+We lazily read the remotenames file once to figure out the potential 
entries
 and store them in self.potentialentries. Then when asked to resolve an
 entry, if it is not in self.potentialentries, then it isn't there, if it
 is in self.potentialentries we resolve it and store the result in
@@ -293,10 +293,11 @@
 self.potentialentries = {}
 self._kind = kind # bookmarks or branches
 self._repo = repo
-self._load()
+self.loaded = False
 
 def _load(self):
 """Read the remotenames file, store entries matching selected kind"""
+self.loaded = True
 repo = self._repo
 alias_default = repo.ui.configbool('remotenames', 'alias.default')
 for node, nametype, remote, rname in readremotenames(repo):
@@ -328,6 +329,8 @@
 return [binnode]
 
 def __getitem__(self, key):
+if not self.loaded:
+self._load()
 val = self._fetchandcache(key)
 if val is not None:
 return val
@@ -345,6 +348,8 @@
 return None
 
 def keys(self):
+if not self.loaded:
+self._load()
 for u in self.potentialentries.keys():
 self._fetchandcache(u)
 return self.cache.keys()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH V3] rebase: fail-fast the pull if working dir is not clean (BC)

[Pierre-Yves David]

note: you sent a V4, before we solved the question in this email. On a 
general basis it is better to wait for open question to be solved before 
sending a new version. It is now a huge deal but it help reduce 
confusion on my side. I'll reply to this email based on V3.


On 01/06/2017 09:48 AM, Valters Vingolds wrote:

Hi, here's my thinking: the default output might be too terse:
$ hg pull --rebase
abort: uncommitted changes

So if a person feels confused by this response ("hold up, what's going
on?"), and passes "--debug" flag they will receive following output:
$ hg pull --rebase --debug
before rebase: ensure working dir is clean
abort: uncommitted changes

In my mind, this is valuable bit of context: oh, that's because "rebase"
is in the mix, and is stopping the pull now.


Ha, right, the terse output can be confusing, and the debug output 
helps, "sold".


I don't think --debug is the best answer here, as I don't expect user to 
see about it and if they use it that might scare them. But having it is 
better than nothing.


A better answer would be to improves the abort message by providing a 
way to specify the "action" check uncommited and unfinished for. That 
does not seems to complicated to do but that is still a scope bloat from 
your current work so I'll take a version with the debug things.



Regarding fake .hg/rebasestate in test, that's literally all that
cmdutil.checkunfinished() does:
  if repo.vfs.exists(f):
  raise error.Abort(msg, hint=hint)

It only checks for existence of named file. And "unfinishedstates" is a
list of file names where plugins register their "operation in progress"
status files...

Conversely, in rebase plugin, to store its state, we only do: "f =
repo.vfs("rebasestate", "w")" and go ahead to write stuff into it.

To test properly, I would have to induce an aborted rebase: generate a
conflict during rebase, and there are existing tests that do it in
rebase-abort testcases. (Or maybe aborted graft is easier to set up.)

I'll think about this, but it is not clear to me if the upside (proper
test) outweighs the downside (complex, maybe brittle set-up), to avoid
internal knowledge of cmdutil.checkunfinished() behavior [which, we
know, in the end only will check for an existence of state-file in .hg/
dir]...


Testing normal user flow seems a better idea than testing implementation 
details. I can think of simpler way to check for unfinished state. For 
example a small histedit session (using edit) can create such condition 
in a simpler way. That seems simple enough to setup with be worth 
trading the hack for it. What do you think ?


Cheers,

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

[PATCH 1 of 6 V5] cmdutil: add missing "i18n" comment about "trouble: " line

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1483702581 -3600
#  Fri Jan 06 12:36:21 2017 +0100
# Node ID 8cb7662ab0192840380a3ce8f521b9ff38a0bbb2
# Parent  13d94304c8daa1fea0551ffb39b2ca3da40e92d7
# EXP-Topic evolve-ui
cmdutil: add missing "i18n" comment about "trouble: " line

Follow-up on f05ede08dcf7 per late review.

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -1257,6 +1257,7 @@ class changeset_printer(object):
   label='log.date')
 
 if ctx.troubled():
+# i18n: column positioning for "hg log"
 self.ui.write(_("trouble: %s\n") % ', '.join(ctx.troubles()),
   label='ui.note log.trouble')
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 6 V5] test: test "trouble: " line in log output with multiple troubles

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1483714102 -3600
#  Fri Jan 06 15:48:22 2017 +0100
# Node ID 6825cb51c2e830cbd28ca326587d1771dadf2cf2
# Parent  8cb7662ab0192840380a3ce8f521b9ff38a0bbb2
# EXP-Topic evolve-ui
test: test "trouble: " line in log output with multiple troubles

Follow-up on f05ede08dcf7.

diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
--- a/tests/test-obsolete.t
+++ b/tests/test-obsolete.t
@@ -798,6 +798,18 @@ reenable for later test
 
 #endif
 
+Several troubles on the same changeset (create an unstable and bumped 
changeset)
+
+  $ hg debugobsolete `getid obsolete_e`
+  $ hg debugobsolete `getid original_c` `getid babar`
+  $ hg log --config ui.logtemplate= -r 'bumped() and unstable()'
+  changeset:   7:50c51b361e60
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  trouble: unstable, bumped
+  summary: add babar
+  
+
 Test incoming/outcoming with changesets obsoleted remotely, known locally
 ===
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 5 of 6 V5] summary: use the same labels as log command in "parent: " line

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1483709674 -3600
#  Fri Jan 06 14:34:34 2017 +0100
# Node ID 1d9bdfeb0afded737513f51e75cefa11e9231fdf
# Parent  87399b8a6ae5a1c38c4969d705a358ba17d7dffd
# EXP-Topic evolve-ui
summary: use the same labels as log command in "parent: " line

Re-use the cmdutil._changesetlabels function introduced in 5289fd78017a to
have consistent labels between the "changeset: " line in log command and the
"parent: " line in summary.

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -5982,7 +5982,7 @@ def summary(ui, repo, **opts):
 # shows a working directory parent *changeset*:
 # i18n: column positioning for "hg summary"
 ui.write(_('parent: %d:%s ') % (p.rev(), str(p)),
- label='log.changeset changeset.%s' % p.phasestr())
+ label=cmdutil._changesetlabels(p))
 ui.write(' '.join(p.tags()), label='log.tag')
 if p.bookmarks():
 marks.extend(p.bookmarks())
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 6 V5] templatekw: add a "troubles" template keyword

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1483707016 -3600
#  Fri Jan 06 13:50:16 2017 +0100
# Node ID bf1e87a41962c793ae1c0ce361cd79aac3f98f1c
# Parent  6825cb51c2e830cbd28ca326587d1771dadf2cf2
# EXP-Topic evolve-ui
templatekw: add a "troubles" template keyword

The "troubles" template keyword returns a list of evolution troubles.
It is EXPERIMENTAL, as anything else related to changeset evolution.

Test it in test-obsolete.t which has troubled changesets.

diff --git a/mercurial/templatekw.py b/mercurial/templatekw.py
--- a/mercurial/templatekw.py
+++ b/mercurial/templatekw.py
@@ -595,5 +595,13 @@ def termwidth(repo, ctx, templ, **args):
 """Integer. The width of the current terminal."""
 return repo.ui.termwidth()
 
+@templatekeyword('troubles')
+def showtroubles(**args):
+"""List of strings. Evolution troubles affecting the changeset.
+
+(EXPERIMENTAL)
+"""
+return showlist('trouble', args['ctx'].troubles(), **args)
+
 # tell hggettext to extract docstrings from these functions:
 i18nfunctions = keywords.values()
diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
--- a/tests/test-obsolete.t
+++ b/tests/test-obsolete.t
@@ -3,7 +3,7 @@
   > # public changeset are not obsolete
   > publish=false
   > [ui]
-  > logtemplate="{rev}:{node|short} ({phase}) [{tags} {bookmarks}] 
{desc|firstline}\n"
+  > logtemplate="{rev}:{node|short} ({phase}{if(troubles, ' {troubles}')}) 
[{tags} {bookmarks}] {desc|firstline}\n"
   > EOF
   $ mkcommit() {
   >echo "$1" > "$1"
@@ -203,7 +203,7 @@ Check that public changeset are not acco
 
   $ hg --hidden phase --public 2
   $ hg log -G
-  @  5:5601fb93a350 (draft) [tip ] add new_3_c
+  @  5:5601fb93a350 (draft bumped) [tip ] add new_3_c
   |
   | o  2:245bde4270cd (public) [ ] add original_c
   |/
@@ -220,7 +220,7 @@ note that the bumped changeset (5:5601fb
 the public changeset
 
   $ hg log --hidden -r 'bumped()'
-  5:5601fb93a350 (draft) [tip ] add new_3_c
+  5:5601fb93a350 (draft bumped) [tip ] add new_3_c
 
 And that we can't push bumped changeset
 
@@ -485,7 +485,7 @@ detect outgoing obsolete and unstable
   phases: 3 draft
   unstable: 1 changesets
   $ hg log -G -r '::unstable()'
-  @  5:cda648ca50f5 (draft) [tip ] add original_e
+  @  5:cda648ca50f5 (draft unstable) [tip ] add original_e
   |
   x  4:94b33453f93b (draft) [ ] add original_d
   |
@@ -527,7 +527,7 @@ Don't try to push extinct changeset
   2:245bde4270cd (public) [ ] add original_c
   3:6f9641995072 (draft) [ ] add n3w_3_c
   4:94b33453f93b (draft) [ ] add original_d
-  5:cda648ca50f5 (draft) [tip ] add original_e
+  5:cda648ca50f5 (draft unstable) [tip ] add original_e
   $ hg push ../tmpf -f # -f because be push unstable too
   pushing to ../tmpf
   searching for changes
@@ -548,7 +548,7 @@ no warning displayed
 Do not warn about new head when the new head is a successors of a remote one
 
   $ hg log -G
-  @  5:cda648ca50f5 (draft) [tip ] add original_e
+  @  5:cda648ca50f5 (draft unstable) [tip ] add original_e
   |
   x  4:94b33453f93b (draft) [ ] add original_d
   |
@@ -810,6 +810,11 @@ Several troubles on the same changeset (
   summary: add babar
   
 
+test the "troubles" templatekw
+
+  $ hg log -r 'bumped() and unstable()'
+  7:50c51b361e60 (draft unstable bumped) [ ] add babar
+
 Test incoming/outcoming with changesets obsoleted remotely, known locally
 ===
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 6 of 6 V5] summary: add evolution "troubles" information to summary output

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1483709722 -3600
#  Fri Jan 06 14:35:22 2017 +0100
# Node ID 3a382f7173808665968de416db145ade8c56672c
# Parent  1d9bdfeb0afded737513f51e75cefa11e9231fdf
# EXP-Topic evolve-ui
summary: add evolution "troubles" information to summary output

Extend the "parent: " lines in summary with the list of evolution "troubles"
in parentheses, when the parent is troubled.

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -5991,6 +5991,15 @@ def summary(ui, repo, **opts):
 ui.write(_(' (empty repository)'))
 else:
 ui.write(_(' (no revision checked out)'))
+if p.troubled():
+ui.write(' (')
+troubles = p.troubles()
+for idx, trouble in enumerate(troubles, 1):
+ui.write(trouble,
+ label='trouble.%s' % trouble)
+if idx < len(troubles):
+ui.write(', ')
+ui.write(')')
 ui.write('\n')
 if p.description():
 ui.status(' ' + p.description().splitlines()[0].strip() + '\n',
diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
--- a/tests/test-obsolete.t
+++ b/tests/test-obsolete.t
@@ -242,7 +242,7 @@ Fixing "bumped" situation
 We need to create a clone of 5 and add a special marker with a flag
 
   $ hg summary
-  parent: 5:5601fb93a350 tip
+  parent: 5:5601fb93a350 tip (bumped)
add new_3_c
   branch: default
   commit: (clean)
@@ -477,7 +477,7 @@ detect outgoing obsolete and unstable
   $ hg log -r 'obsolete()'
   4:94b33453f93b (draft) [ ] add original_d
   $ hg summary
-  parent: 5:cda648ca50f5 tip
+  parent: 5:cda648ca50f5 tip (unstable)
add original_e
   branch: default
   commit: (clean)
@@ -825,6 +825,20 @@ test the default cmdline template
   summary: add babar
   
 
+test summary output
+
+  $ hg up -r 'bumped() and unstable()'
+  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ hg summary
+  parent: 7:50c51b361e60  (unstable, bumped)
+   add babar
+  branch: default
+  commit: 3 unknown (clean)
+  update: 2 new changesets (update)
+  phases: 4 draft
+  unstable: 2 changesets
+  bumped: 1 changesets
+
 Test incoming/outcoming with changesets obsoleted remotely, known locally
 ===
 
diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
--- a/tests/test-rebase-obsolete.t
+++ b/tests/test-rebase-obsolete.t
@@ -761,7 +761,7 @@ If a rebase is going to create divergenc
   o  0:4a2df7238c3b A
   
   $ hg summary
-  parent: 15:73568ab6879d tip
+  parent: 15:73568ab6879d tip (unstable)
bar foo
   branch: default
   commit: (clean)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 4 of 6 V5] templates: display evolution "troubles" in command line style

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1483707052 -3600
#  Fri Jan 06 13:50:52 2017 +0100
# Node ID 87399b8a6ae5a1c38c4969d705a358ba17d7dffd
# Parent  bf1e87a41962c793ae1c0ce361cd79aac3f98f1c
# EXP-Topic evolve-ui
templates: display evolution "troubles" in command line style

diff --git a/mercurial/templates/map-cmdline.default 
b/mercurial/templates/map-cmdline.default
--- a/mercurial/templates/map-cmdline.default
+++ b/mercurial/templates/map-cmdline.default
@@ -1,9 +1,9 @@
 # Base templates. Due to name clashes with existing keywords, we have
 # to replace some keywords with 'lkeyword', for 'labelled keyword'
-changeset = 
'{cset}{branches}{bookmarks}{tags}{parents}{user}{ldate}{summary}\n'
+changeset = 
'{cset}{branches}{bookmarks}{tags}{parents}{user}{ldate}{ltroubles}{summary}\n'
 changeset_quiet = '{lnode}'
-changeset_verbose = 
'{cset}{branches}{bookmarks}{tags}{parents}{user}{ldate}{lfiles}{lfile_copies_switch}{description}\n'
-changeset_debug = 
'{fullcset}{branches}{bookmarks}{tags}{lphase}{parents}{manifest}{user}{ldate}{lfile_mods}{lfile_adds}{lfile_dels}{lfile_copies_switch}{extras}{description}\n'
+changeset_verbose = 
'{cset}{branches}{bookmarks}{tags}{parents}{user}{ldate}{ltroubles}{lfiles}{lfile_copies_switch}{description}\n'
+changeset_debug = 
'{fullcset}{branches}{bookmarks}{tags}{lphase}{parents}{manifest}{user}{ldate}{ltroubles}{lfile_mods}{lfile_adds}{lfile_dels}{lfile_copies_switch}{extras}{description}\n'
 
 # File templates
 lfiles = '{if(files,
@@ -28,7 +28,8 @@ lfile_copies_switch = '{if(file_copies_s
% ' {name} ({source})'}\n"))}'
 
 # General templates
-_cset_labels = 'log.changeset changeset.{phase}'
+_trouble_label = 'trouble.{trouble}'
+_cset_labels = 'log.changeset changeset.{phase}{if(troubles, " 
changeset.troubled {troubles%_trouble_label}")}'
 cset = '{label("{_cset_labels}",
"changeset:   {rev}:{node|short}")}\n'
 
@@ -65,6 +66,9 @@ summary = '{if(desc|strip, "{label('log.
 ldate = '{label("log.date",
 "date:{date|date}")}\n'
 
+ltroubles = '{if(troubles, "{label('ui.note log.trouble',
+   'trouble: {join(troubles, ", 
")}')}\n")}'
+
 extra = '{label("ui.debug log.extra",
 "extra:   {key}={value|stringescape}")}\n'
 
diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t
--- a/tests/test-obsolete.t
+++ b/tests/test-obsolete.t
@@ -815,6 +815,16 @@ test the "troubles" templatekw
   $ hg log -r 'bumped() and unstable()'
   7:50c51b361e60 (draft unstable bumped) [ ] add babar
 
+test the default cmdline template
+
+  $ hg log -T default -r 'bumped()'
+  changeset:   7:50c51b361e60
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  trouble: unstable, bumped
+  summary: add babar
+  
+
 Test incoming/outcoming with changesets obsoleted remotely, known locally
 ===
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH evolve-ext] fold: disallow multiple revisions without --exact

[Pierre-Yves David]

On 01/04/2017 10:47 PM, Martin von Zweigbergk wrote:

On Wed, Jan 4, 2017 at 11:40 AM, Pierre-Yves David
 wrote:

On 01/04/2017 05:38 PM, Martin von Zweigbergk wrote:

On Wed, Jan 4, 2017 at 4:53 AM, Pierre-Yves David
 wrote:

On 12/18/2016 06:36 PM, Martin von Zweigbergk via Mercurial-devel wrote:

On Fri, Dec 16, 2016, 23:53 Pierre-Yves David
>
wrote:
On 11/05/2016 12:58 AM, Martin von Zweigbergk via Mercurial-devel
wrote:
> # HG changeset patch
> # User Martin von Zweigbergk >
> # Date 1478303512 25200
> #  Fri Nov 04 16:51:52 2016 -0700
> # Node ID bb80851fe9a6e14263f0076074108556377141f9
> # Parent  cb2bac3253fbd52894ffcb4719a148fe6a3da38b
> fold: disallow multiple revisions without --exact

[…]

Currently I would weight "constraint" that way
(more important to least important):

 (1) no revset knowledge required:
 simplicity is very important,


That makes sense, but note that "hg fold -r foo -r bar" is already
supported and does not require the user to know about revsets (and one
can also drop the "-r"s in that command). I feel like you're assuming
that defaulting to --exact requires the user to know about revsets. I
don't see it that way.


The "specify multiple revs" approach "works" but is quickly cumbersome and
error prone if you have more than a couple changesets.

There is currently two others tools that someone can use to fold changesets:
 * hg rebase --collapse
 * hg histedit
Both provide the user with a simple way to fold many changesets (eg: by
providing a root). So a kind of bottom line here is that it would be really
awkward if the command dedicated to folding changeset end up being less user
friendly than command dedicated to other usecase (that happen to be able to
fold things as a secondary feature).

This made me implicitly discard the option to "list every single changeset
to be folded" from the "viable UI" list.  Thanks for pointing this out. It
gave me the chance to unearth that extra criteria: "be a better UI than the
existing solution".

What do you think ?


Thanks for mentioning rebase. Rebase has various ways of specifying
which revisions to rebase (-b,-s,-r). It also has a default, which I
consider a mistake.


Actually, rebase has two defaults:

- The default destination:
It used to be pretty bad, working only in the simplest case and 
being harmful in all the others. However, this actually got fixed last 
year and it now pretty okay. It even has the potential to become pretty 
awesome once we have a good story regarding feature branches and names. 
See associated wiki page for details:

https://www.mercurial-scm.org/wiki/DefaultDestinationPlan

- The default rebase set: (-b .)
It seems to fit the needs in most case and I don't think I've seen 
much complains about it. We can probably improve that a bit when we get 
a good "current working set" story through feature branch.


I agree that bad default are mistake, but good default are great and 
have been a good advantage of Mercurial. We should keep aiming at good 
default whenever we can.



So, how about making "hg fold" not have a default?
I suggest we ask the user to say either "hg fold --from=$rev" to get
the behavior they currently get by default, and "hg fold -r $revset"
(or "hg fold -r $rev1 -r $rev2" for beginners). Note that I'm
suggesting that --exact will not be needed (and can be deprecated),
because I don't like to have the argument passed to -r be used for
different things based on that flag. How does that sound?


The --from things is to consider, it seems to match our current 
constraint including the one about not being worse than the existing 
solution (It does not strike me as much better, but at least not worse). 
Not sure about the word since we might want to allow it to specify 
descendant too (not just ancestors).


I'm not sure what you mean with the --rev flag. Do you mean that default 
entry would be revset? Or that --rev would trigger the revset mode? or 
something else? Previous discussion on the topic concluded that having 
mode switch on --rev wasn't a good idea.


In all case, that discussion is getting deeper and we should switch to VC.


[…]


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

mercurial@30708: 6 new changesets

[Mercurial Commits]

6 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/5c85c93cdd61
changeset:   30703:5c85c93cdd61
user:Sean Farley 
date:Sat Dec 31 15:36:36 2016 -0600
summary: cmdutil: add special string that ignores rest of text

https://www.mercurial-scm.org/repo/hg/rev/0499da0d5a06
changeset:   30704:0499da0d5a06
user:Sean Farley 
date:Wed Jan 04 22:32:42 2017 -0600
summary: config: add docs for ignoring all text below in the editor

https://www.mercurial-scm.org/repo/hg/rev/06b17f6c6559
changeset:   30705:06b17f6c6559
user:Anton Shestakov 
date:Fri Jan 06 09:56:40 2017 +0800
summary: make: remove targets for building packages for ubuntu wily (end of 
life)

https://www.mercurial-scm.org/repo/hg/rev/2e4862646f02
changeset:   30706:2e4862646f02
user:Martin von Zweigbergk 
date:Wed Jan 04 10:07:12 2017 -0800
summary: repair: speed up stripping of many roots

https://www.mercurial-scm.org/repo/hg/rev/987dbe87aad6
changeset:   30707:987dbe87aad6
user:Martin von Zweigbergk 
date:Wed Jan 04 10:35:04 2017 -0800
summary: repair: combine two loops over changelog revisions

https://www.mercurial-scm.org/repo/hg/rev/011122b3b1c4
changeset:   30708:011122b3b1c4
bookmark:@
tag: tip
user:Gregory Szorc 
date:Wed Dec 28 15:48:17 2016 -0700
summary: hgweb: link to raw-file on annotation page (BC)

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

Re: [PATCH 1 of 3 V4] rebase: fail-fast the pull if working dir is not clean (BC)

[Pierre-Yves David]

On 01/06/2017 04:11 PM, Valters Vingolds wrote:

# HG changeset patch
# User Valters Vingolds 
# Date 1483272989 -3600
#  Sun Jan 01 13:16:29 2017 +0100
# Node ID ba648b03fc21c8213d580c8ed193002511e3f872
# Parent  011122b3b1c42374fb0489d107418e1be3665ca6
rebase: fail-fast the pull if working dir is not clean (BC)


We still have a discussion in progress on V3, so I'm surprised to see a 
V4. Let us slow down a bit here.


I was about to reply to your last message about V3. What's the change 
and motivation in V4 ?




Refuse to run 'hg pull --rebase' if there are uncommitted changes:
so that instead of going ahead with fetching changes and then suddenly aborting
the rebase, we can warn user of uncommitted changes (or unclean repo state)
right up front.

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1316,6 +1316,10 @@
 ui.debug('--update and --rebase are not compatible, ignoring '
  'the update flag\n')

+ui.debug('before rebase: ensure working dir is clean\n')
+cmdutil.checkunfinished(repo)
+cmdutil.bailifchanged(repo)
+
 revsprepull = len(repo)
 origpostincoming = commands.postincoming
 def _dummy(*args, **kwargs):
diff --git a/tests/test-rebase-pull.t b/tests/test-rebase-pull.t
--- a/tests/test-rebase-pull.t
+++ b/tests/test-rebase-pull.t
@@ -72,6 +72,19 @@
   searching for changes
   no changes found

+Abort pull early if working dir is not clean:
+
+  $ echo L1-mod > L1
+  $ hg pull --rebase
+  abort: uncommitted changes
+  [255]
+  $ hg update --clean --quiet
+  $ touch .hg/rebasestate # make rebase think there's one in progress right now
+  $ hg pull --rebase
+  abort: rebase in progress
+  (use 'hg rebase --continue' or 'hg rebase --abort')
+  [255]
+  $ rm .hg/rebasestate

 Invoke pull --rebase and nothing to rebase:

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



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

[PATCH 1 of 3 V4] rebase: fail-fast the pull if working dir is not clean (BC)

[Valters Vingolds]

# HG changeset patch
# User Valters Vingolds 
# Date 1483272989 -3600
#  Sun Jan 01 13:16:29 2017 +0100
# Node ID ba648b03fc21c8213d580c8ed193002511e3f872
# Parent  011122b3b1c42374fb0489d107418e1be3665ca6
rebase: fail-fast the pull if working dir is not clean (BC)

Refuse to run 'hg pull --rebase' if there are uncommitted changes:
so that instead of going ahead with fetching changes and then suddenly aborting
the rebase, we can warn user of uncommitted changes (or unclean repo state)
right up front.

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1316,6 +1316,10 @@
 ui.debug('--update and --rebase are not compatible, ignoring '
  'the update flag\n')
 
+ui.debug('before rebase: ensure working dir is clean\n')
+cmdutil.checkunfinished(repo)
+cmdutil.bailifchanged(repo)
+
 revsprepull = len(repo)
 origpostincoming = commands.postincoming
 def _dummy(*args, **kwargs):
diff --git a/tests/test-rebase-pull.t b/tests/test-rebase-pull.t
--- a/tests/test-rebase-pull.t
+++ b/tests/test-rebase-pull.t
@@ -72,6 +72,19 @@
   searching for changes
   no changes found
 
+Abort pull early if working dir is not clean:
+
+  $ echo L1-mod > L1
+  $ hg pull --rebase
+  abort: uncommitted changes
+  [255]
+  $ hg update --clean --quiet
+  $ touch .hg/rebasestate # make rebase think there's one in progress right now
+  $ hg pull --rebase
+  abort: rebase in progress
+  (use 'hg rebase --continue' or 'hg rebase --abort')
+  [255]
+  $ rm .hg/rebasestate
 
 Invoke pull --rebase and nothing to rebase:
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 3 V4] rebase tests: verify that we will abort pull early during graft in progress

[Valters Vingolds]

# HG changeset patch
# User Valters Vingolds 
# Date 1483701359 -3600
#  Fri Jan 06 12:15:59 2017 +0100
# Node ID f9ef0679fabea8ef0ab65aa7f76258e248473a8e
# Parent  ba648b03fc21c8213d580c8ed193002511e3f872
rebase tests: verify that we will abort pull early during graft in progress

Created (a bit involved) test that generates a graft in-progress state,
and check that pull with --rebase will abort early if working state is unclean.

diff --git a/tests/test-rebase-pull.t b/tests/test-rebase-pull.t
--- a/tests/test-rebase-pull.t
+++ b/tests/test-rebase-pull.t
@@ -86,6 +86,43 @@
   [255]
   $ rm .hg/rebasestate
 
+Abort pull early if another operation (graft) is in progress:
+  $ cd ..
+  $ hg clone a d --noupdate
+  $ cd d
+  $ hg update 0 --quiet
+  $ echo original > graft-conflict.txt
+  $ hg commit -A -m "graft source" # = rev 3
+  adding graft-conflict.txt
+  created new head
+  $ hg update 2 --quiet
+  $ echo conflict > graft-conflict.txt
+  $ hg commit -A -m "graft target" # = rev 4
+  adding graft-conflict.txt
+  $ hg tglog
+  @  4: 'graft target'
+  |
+  | o  3: 'graft source'
+  | |
+  o |  2: 'R1'
+  | |
+  o |  1: 'C2'
+  |/
+  o  0: 'C1'
+  
+  $ hg graft 3 # on top of rev 4: will fail
+  grafting 3:63be2bb2afb6 "graft source"
+  merging graft-conflict.txt
+  warning: conflicts while merging graft-conflict.txt! (edit, then use 'hg 
resolve --mark')
+  abort: unresolved conflicts, can't continue
+  (use 'hg resolve' and 'hg graft --continue')
+  [255]
+  $ hg pull --rebase
+  abort: graft in progress
+  (use 'hg graft --continue' or 'hg update' to abort)
+  [255]
+
+
 Invoke pull --rebase and nothing to rebase:
 
   $ cd ../c
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3 V4] rebase tests: remove test that touched 'rebasestate' directly

[Valters Vingolds]

# HG changeset patch
# User Valters Vingolds 
# Date 1483701570 -3600
#  Fri Jan 06 12:19:30 2017 +0100
# Node ID 7dbf18edd08f5de0c74df8b3256bc62146081dd0
# Parent  f9ef0679fabea8ef0ab65aa7f76258e248473a8e
rebase tests: remove test that touched 'rebasestate' directly

diff --git a/tests/test-rebase-pull.t b/tests/test-rebase-pull.t
--- a/tests/test-rebase-pull.t
+++ b/tests/test-rebase-pull.t
@@ -79,12 +79,6 @@
   abort: uncommitted changes
   [255]
   $ hg update --clean --quiet
-  $ touch .hg/rebasestate # make rebase think there's one in progress right now
-  $ hg pull --rebase
-  abort: rebase in progress
-  (use 'hg rebase --continue' or 'hg rebase --abort')
-  [255]
-  $ rm .hg/rebasestate
 
 Abort pull early if another operation (graft) is in progress:
   $ cd ..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 2] commit: update test to actually modify template text

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1483710279 -32400
#  Fri Jan 06 22:44:39 2017 +0900
# Node ID b5247f031aed69bb2f7c6a3a8d1c9b076a7384d5
# Parent  011122b3b1c42374fb0489d107418e1be3665ca6
commit: update test to actually modify template text

We have a check for unmodified commit message (introduced by bec1a579ebc4),
which should be enabled for the "--- >8 ---" magic but currently not.

diff --git a/tests/test-commit.t b/tests/test-commit.t
--- a/tests/test-commit.t
+++ b/tests/test-commit.t
@@ -692,6 +692,11 @@ verify pathauditor blocks evil filepaths
 
 test that text below the --- >8 --- special string is ignored
 
+  $ cat <<'EOF' > $TESTTMP/lowercaseline.sh
+  > cat $1 | sed s/LINE/line/ | tee $1.new
+  > mv $1.new $1
+  > EOF
+
   $ hg init ignore_below_special_string
   $ cd ignore_below_special_string
   $ echo foo > foo
@@ -699,7 +704,7 @@ test that text below the --- >8 --- spec
   $ hg commit -m "foo"
   $ cat >> .hg/hgrc < [committemplate]
-  > changeset.commit = first line
+  > changeset.commit = first LINE
   > HG: this is customized commit template
   > HG: {extramsg}
   > HG:  >8 
@@ -707,7 +712,7 @@ test that text below the --- >8 --- spec
   > EOF
   $ echo foo2 > foo2
   $ hg add foo2
-  $ HGEDITOR=cat hg ci
+  $ HGEDITOR="sh $TESTTMP/lowercaseline.sh" hg ci
   first line
   HG: this is customized commit template
   HG: Leave message empty to abort commit.
@@ -725,7 +730,7 @@ a line
 
   $ cat >> .hg/hgrc < [committemplate]
-  > changeset.commit = first line2
+  > changeset.commit = first LINE2
   > another line HG:  >8 
   > HG: this is customized commit template
   > HG: {extramsg}
@@ -733,7 +738,7 @@ a line
   > {diff()}
   > EOF
   $ echo foo >> foo
-  $ HGEDITOR=cat hg ci
+  $ HGEDITOR="sh $TESTTMP/lowercaseline.sh" hg ci
   first line2
   another line HG:  >8 
   HG: this is customized commit template
@@ -754,7 +759,7 @@ at the end
 
   $ cat >> .hg/hgrc < [committemplate]
-  > changeset.commit = first line3
+  > changeset.commit = first LINE3
   > HG:  >8 foobar
   > second line
   > HG: this is customized commit template
@@ -763,7 +768,7 @@ at the end
   > {diff()}
   > EOF
   $ echo foo >> foo
-  $ HGEDITOR=cat hg ci
+  $ HGEDITOR="sh $TESTTMP/lowercaseline.sh" hg ci
   first line3
   HG:  >8 foobar
   second line
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2] commit: fix unmodified message detection for the "--- >8 ----" magic

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1483710604 -32400
#  Fri Jan 06 22:50:04 2017 +0900
# Node ID d19726fc559971501161eba3552f96a93a3a5c25
# Parent  b5247f031aed69bb2f7c6a3a8d1c9b076a7384d5
commit: fix unmodified message detection for the "--- >8 " magic

We need the raw editortext to be compared with the templatetext.

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -2771,14 +2771,15 @@ def commitforceeditor(repo, ctx, subs, f
 
 editortext = repo.ui.edit(committext, ctx.user(), ctx.extra(),
 editform=editform, pending=pending)
+text = editortext
 
 # strip away anything below this special string (used for editors that want
 # to display the diff)
-stripbelow = re.search(_linebelow, editortext, flags=re.MULTILINE)
+stripbelow = re.search(_linebelow, text, flags=re.MULTILINE)
 if stripbelow:
-editortext = editortext[:stripbelow.start()]
-
-text = re.sub("(?m)^HG:.*(\n|$)", "", editortext)
+text = text[:stripbelow.start()]
+
+text = re.sub("(?m)^HG:.*(\n|$)", "", text)
 os.chdir(olddir)
 
 if finishdesc:
diff --git a/tests/test-commit.t b/tests/test-commit.t
--- a/tests/test-commit.t
+++ b/tests/test-commit.t
@@ -712,6 +712,9 @@ test that text below the --- >8 --- spec
   > EOF
   $ echo foo2 > foo2
   $ hg add foo2
+  $ HGEDITOR="sh $TESTTMP/notouching.sh" hg ci
+  abort: commit message unchanged
+  [255]
   $ HGEDITOR="sh $TESTTMP/lowercaseline.sh" hg ci
   first line
   HG: this is customized commit template
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] rebase: replace stray call of 'os.path.exists' with repo.vfs.exists at 'hg summary' hook

[Pierre-Yves David]

On 01/06/2017 10:18 AM, Valters Vingolds wrote:

# HG changeset patch
# User Valters Vingolds 
# Date 1483693121 -3600
#  Fri Jan 06 09:58:41 2017 +0100
# Node ID 80ce9f02d8481f8d22d057753088283522cc2539
# Parent  62a41fd87dabf0e6fb631a9e9ba1aabfe7e0f801
rebase: replace stray call of 'os.path.exists' with repo.vfs.exists at 'hg 
summary' hook


I've pushed this, our commit checker was complaining about the summary 
lenght, I've updated it to:


  rebase: use repo.vfs.exists in 'hg summary' hook

Thanks,

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

[PATCH] rebase: replace stray call of 'os.path.exists' with repo.vfs.exists at 'hg summary' hook

[Valters Vingolds]

# HG changeset patch
# User Valters Vingolds 
# Date 1483693121 -3600
#  Fri Jan 06 09:58:41 2017 +0100
# Node ID 80ce9f02d8481f8d22d057753088283522cc2539
# Parent  62a41fd87dabf0e6fb631a9e9ba1aabfe7e0f801
rebase: replace stray call of 'os.path.exists' with repo.vfs.exists at 'hg 
summary' hook

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1428,7 +1428,7 @@
 return obsoletenotrebased
 
 def summaryhook(ui, repo):
-if not os.path.exists(repo.join('rebasestate')):
+if not repo.vfs.exists('rebasestate'):
 return
 try:
 rbsrt = rebaseruntime(repo, ui, {})
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] hgweb: link to raw-file on annotation page (BC)

[Pierre-Yves David]

On 01/04/2017 07:06 PM, Gregory Szorc wrote:



On Jan 4, 2017, at 07:37, Pierre-Yves David  
wrote:


On 12/28/2016 11:53 PM, Gregory Szorc wrote:
# HG changeset patch
# User Gregory Szorc 
# Date 1482965297 25200
#  Wed Dec 28 15:48:17 2016 -0700
# Node ID 4a560014d6d64edcefb1d431e882824771c5ae15
# Parent  dc5b594f41e9be5820ce3f197d3817379b2d3af5
hgweb: link to raw-file on annotation page (BC)

Every other template has the "raw" link load "raw-file." However,
fileannotate.tmpl's "raw" link loads "raw-annotate." This feels
inconsistent and wrong.


Hum, yeah not being served the raw file content when clicking on raw is 
definitely surprising. So I'm leaning toward taking this.

Is there another way to access the raw-annotate (beside url writing) after your 
change? (that page looks like a strange thing people would not use, but who can 
predict users in the wild).


No. But it would be trivial to add if users complain. I feel this has been an 
accidental link for years and nobody has noticed until now. That's why I 
dropped the link completely.


I lean to agree here. I've pushed it with an extra ping to other 
reviewers to increase the chance of someone complaining if he disagree.


Thanks,

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