# HG changeset patch
# User Ludovic Chabant
# Date 1547180577 28800
# Thu Jan 10 20:22:57 2019 -0800
# Node ID 5686d56d5a2cebaa504383b270e359156352090f
# Parent ef0e2f7224358c32b0f62b13e83e89ba2399c8cf
extdiff: add --per-file and --confirm options
The new options lets the user control how
# HG changeset patch
# User Ludovic Chabant
# Date 1546539395 28800
# Thu Jan 03 10:16:35 2019 -0800
# Node ID cc964d5d3e3faca1bbbc680732c38cf785754fc2
# Parent 5a2a6ab7bc37af9294b58edfd4d224706940ff19
extdiff: add --mode option
The new option lets the user control how the external program
# HG changeset patch
# User Ludovic Chabant
# Date 1546539214 28800
# Thu Jan 03 10:13:34 2019 -0800
# Node ID 5a2a6ab7bc37af9294b58edfd4d224706940ff19
# Parent 5c68b617ba2463eb6f1372a24b139a376c6bf6bd
help: fix typo
diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
# HG changeset patch
# User Ludovic Chabant
# Date 1547180523 28800
# Thu Jan 10 20:22:03 2019 -0800
# Node ID ef0e2f7224358c32b0f62b13e83e89ba2399c8cf
# Parent e546c124217485f54b897d050a9573fc4ab97ab7
extdiff: move external tool command line building into separate function
diff --git
# HG changeset patch
# User Ludovic Chabant
# Date 1547180577 28800
# Thu Jan 10 20:22:57 2019 -0800
# Node ID dfda7867497e5609a03727508dc0da2cab3218a3
# Parent ef0e2f7224358c32b0f62b13e83e89ba2399c8cf
extdiff: add --mode option
The new option lets the user control how the external program
> Sorry for late review. Almost all devs were inactive while holidays.
No worries! Between the holidays and the 4.8.2 release, I figured unsolicited
new features were a low priority.
> First, can you break this into a series of a few patches?
>
>
> First, can you break this into a series of a few patches?
As you might have seen, I sent the change split in 2 patches to the mailing
list. I didn't change anything else yet, so we can keep discussing the CLI on
the new patch. Thanks!
--
l u d o .
. 8 0 17 80
> I was just speaking about the current implementation (without your patch.)
> Maybe I should say .gui flag isn't checked because the current extdiff never
> spawns more than one processes at a time.
Yeah, and I meant that I don't understand what's the difference between one vs.
multiple
Thanks for the comments!
> Maybe need to check the .gui flag of the tool. Otherwise the console
> would be messed up if the tool wasn't a GUI program.
Good point, although the existing extdiff code doesn't seem to be checking
that, no? So should I do that in a separate patch?
> Well, I think
> A separate patch seems fine. To make clear, there's no need to check if the
> tool is console-based or not unless multiple diff processes are spawned
> simultaneously. Currently the .gui flag is tested only by filemerge.py.
So you mean I don't need to modify the previous code path (dir-diff),
> After sometime of fighting with windows, here I am looking for suggestions on
> how one can use mercurial on windows smoothly and what are the recommended
> ways. Like shall I use MYSYS, did things will work in cmd.exe?
>
> If anyone can shed some light on their experiences and tips and
> I do understand however that it would be easy for users to get in a
> messy situation so I guess I'll add a "--batch" option to "--per-file"
> if that's OK?
Another way to solve this would be to actually default to "--prompt" when
"--per-file" is specified, and require "--no-prompt" if you
> What I pointed out last time was that we shouldn't spawn non-GUI tools
> asynchronously. You can see the problem by the following command on Unix.
>
> $ hg --config extdiff.vimdiff= vimdiff -c. --per-file
Mmmh so for this I figured people would use the "--confirm" flag because, if we
use
> > - This would let us see the doc for, say, `hg status` over at
> > https://www.mercurial-scm.org/doc/hg-status.1.html
>
> As we discussed in IRC, that page already exists, but it's hard
> to find:
>
> https://www.mercurial-scm.org/repo/hg/help/status
Ah yes I forgot to mention that. There's
> On Feb 18, 2019, at 15:30, Jordi Gutiérrez Hermoso
> wrote:
>
> There's an important dogfooding component here. If we think that the
> hgweb docs are useless, then we should completely get rid of them and
> just point people instead to the new docs you're building.
I don’t believe the two
Hi there!
I started playing around with improving the Mercurial docs but before I
work on it more and send some patches, I wanted to get some opinions
about what people would like to see here. Sorry about the length of this
email but there's a lot to do IMHO.
What I have in mind is the following
> Can you split this to a separate patch? It'll need a bit more churn,
> and we wouldn't want to make it a blocker of the --per-file/--confirm
> feature.
I just sent PATCH V4 which should be just that feature alone, where, if
you don't specify --confirm, it launches the external tool one by one.
> Unused in this version. Removed.
>
> Looks like unrelated change. Also removed.
Indeed, sorry, I didn't correctly split my commit in 2. Thanks for the cleanup!
--
l u d o .
. 8 0 17 80
___
Mercurial-devel mailing list
> My idea is basically as follows:
>
> if cmd and opts found in extdiff:
> # it must be a user-defined tool
> look for extdiff.gui.
> elif cmd.diffargs found in diff-tools:
> # perhaps it's a stock tool template defined in [diff-tools] (less
> common)
> look for
> Generally looks good. Can you add some tests?
Oh right, that's another thing I wanted to ask -- how would I test that? The
only idea I have is to log some verbose message ("tool %s has a graphical
interface, launching processes simultaneously") and detect that in test. Is
there any better
# HG changeset patch
# User Ludovic Chabant
# Date 1549173529 28800
# Sat Feb 02 21:58:49 2019 -0800
# Node ID b08ea934c2d5ac097b171ca74e826e4f9dea86a9
# Parent 3a3b053d0882a33ba7ea667052e445b193ffa4df
extdiff: support tools that can be run simultaneously
diff --git a/hgext/extdiff.py b
# HG changeset patch
# User Ludovic Chabant
# Date 1549173509 28800
# Sat Feb 02 21:58:29 2019 -0800
# Node ID 75d87a5ac4d0d26e02d21df87d2a89ac59c6d535
# Parent b08ea934c2d5ac097b171ca74e826e4f9dea86a9
extdiff: don't run gui programs when in a cli-only environment
diff --git a/hgext
One thing I'm not quite sure about this change is how to handle the new "gui"
config flag.
I wanted to use (abuse?) the difference between False and None in order to
figure out if we found the flag in a section or not (and fall back to another
section if not). However, passing None as the
# HG changeset patch
# User Ludovic Chabant
# Date 1549173529 28800
# Sat Feb 02 21:58:49 2019 -0800
# Node ID b8e97fbea8490173387735e72cc424c21d7a1c04
# Parent 3a3b053d0882a33ba7ea667052e445b193ffa4df
extdiff: support tools that can be run simultaneously
diff --git a/hgext/extdiff.py b
> > Oh right, that's another thing I wanted to ask -- how would I test that?
> > The only idea I have is to log some verbose message ("tool %s has a
> > graphical interface, launching processes simultaneously") and detect that
> > in test. Is there any better way?
>
> Something like that.
> Does this make any existing tests for evolve pass on py3?
The evolve extension wasn't even loading in py3 before this patch --
mercurial core would reject it for trying to add unicode strings to the
command table.
> Taking other patches first would mean this patch would be hard to
> apply and
# HG changeset patch
# User Ludovic Chabant
# Date 1555683992 0
# Fri Apr 19 14:26:32 2019 +
# Branch stable
# Node ID 6805ebb0f1f6a7f34a74732ee6f6ec14e8824e42
# Parent 3611368a1af3037427eb59635c7dad8dab67c606
py3: properly reject non-encoded strings given to hgweb
diff --git
# HG changeset patch
# User Ludovic Chabant
# Date 1555683918 0
# Fri Apr 19 14:25:18 2019 +
# Branch stable
# Node ID 3611368a1af3037427eb59635c7dad8dab67c606
# Parent 4a8d9ed864754837a185a642170cde24392f9abf
py3: handle meta-path finders that only use pre-python3.4 API
diff --git
>
> Should opts[x], opts.get(x), etc really use bytes? They usually get passed as
> **opts, which means their keys are str, I think.
>
Sounds OK to me -- there's probably a whole bunch of places that might need to
be excluded. It might be worth exploring doing the opposite approach, i.e.
> We definitely want this patch, but we equally want a way to test (not
> just locally) that it keeps working. Maybe we can better coordinate the
> efforts in #hg-evolve.
Will do, thanks!
___
Mercurial-devel mailing list
> This patch don't apply anymore :-/ It is also very invasive and will be
> painful for all other contributors.
It might be because I created the patch on top of `stable` instead of some
other head?
To be precise it was applied on top of the 9.0 release since that was the
latest on the stable
> I'm curious to hear what Ludovic thinks, but I'm doubtful that saves
> other contributors more time than it costs for Ludovic, so it's a net
> negative.
>
> I assume you know that Python 2's end of life is Jan 1 2020, so this
> is getting urgent. I don't know about others, but my team will need
Thanks for the reply!
> AFAIK, that's by-design thing. What the hgloader does is a bunch
> of weird hacks only valid for our codebase, which we'll eventually
> get rid of.
Then either the design is wrong, or the code is wrong.
First, like I said, depending on *how* you import an extension, it
Should I re-create the patch on the latest evolve stable now? Or will someone
else do it?
I'm asking because py3 support is blocking a few things for sourcehut.
Thanks!
On Sat, May 25, 2019, at 00:05, Ludovic Chabant wrote:
> > Does this make any existing tests for evolve pass
>
> Is there any list of exceptions that are known to be safely
> suppressed? Catching AttributeError, TypeError, etc. seems bad.
>
In my case, it's just a missing method so AttributeError is what's being
raised I think (see
https://github.com/benjaminp/six/blob/master/six.py#L164).
My rationale
> We'll probably need to fix the caller to not pass in a unicode. Can
> you copy-paste the traceback?
The caller is my own code. It's basically a custom version of the
hgweb.wsgi file (see
https://www.mercurial-scm.org/repo/hg/file/tip/contrib/hgweb.wsgi).
If we want to be consistent with other
# HG changeset patch
# User Ludovic Chabant
# Date 1555683918 0
# Fri Apr 19 14:25:18 2019 +
# Branch stable
# Node ID 8214209f30a56052124b7f530d2a955a2b93b14f
# Parent 4a8d9ed864754837a185a642170cde24392f9abf
py3: handle meta-path finders that only use pre-python3.4 API
diff --git
# HG changeset patch
# User Ludovic Chabant
# Date 1555683992 0
# Fri Apr 19 14:26:32 2019 +
# Branch stable
# Node ID eaf4d232055361fd79e5d5299fc76d641be2fb6c
# Parent 8214209f30a56052124b7f530d2a955a2b93b14f
py3: convert unicode paths given for hgweb config
diff --git a/mercurial
> > If we want to be consistent with other things like the hgclient API,
> > maybe we shouldn't be nice and encode the string for the caller, and
> > instead reject anything that's not bytes?
>
> Sounds good to reject unicodes explicitly.
I had sent a v2 of my patch with a better way to encode
>
> Gracefully handling missing find_spec() should be fine. But we should
> use hasattr() or getattr() for that (Mercurial’s linter may insist on
> getattr() because I think we still ban hasattr()) because bare
> “except:” is bad.
Thanks, I sent a v2 of my patches yesterday evening with that
> Does find_module() return a spec? We might instead have to skip py3.4
> finders.
Ah you're right, it returns something else. It looks like Python
does this:
try:
find_spec = finder.find_spec
except AttributeError:
loader = finder.find_module(name)
if loader is
# HG changeset patch
# User Ludovic Chabant
# Date 1555683992 0
# Fri Apr 19 14:26:32 2019 +
# Branch stable
# Node ID b1baf28288faf3fd628d5104211e1482e77bdf39
# Parent 96a51193678400abf9d04af65e60a8dccf540cd7
py3: convert unicode paths given for hgweb config
diff --git a/mercurial
# HG changeset patch
# User Ludovic Chabant
# Date 1555683918 0
# Fri Apr 19 14:25:18 2019 +
# Branch stable
# Node ID 96a51193678400abf9d04af65e60a8dccf540cd7
# Parent 4a8d9ed864754837a185a642170cde24392f9abf
py3: protect from exceptions thrown by other meta-path finders
diff --git
For those who missed my latest adventures on IRC, I recently discovered that
the hgloader (which patches strings and other py3 things at compile time)
doesn't kick in if you load an extension from a specific file-system location.
This means that:
1) If you `pip install hg-evolve` and add
# HG changeset patch
# User Ludovic Chabant
# Date 1561756040 0
# Fri Jun 28 21:07:20 2019 +
# Branch stable
# Node ID 90daf413dfc7a7e4762e6445f05c52b123c6188f
# Parent 756db65030c64b22836fe236d1db3b95477e3ef7
py3: make setup.py py3 compatible
diff --git a/setup.py b/setup.py
> I don't care much about the correctness of the hgloader. It's a temporary
> hack, and Python 3 support is still experimental.
I understand it's experimental but you can expect sourcehut to push somewhat
aggressively on it :)
> > Is the plan to run byteify-strings.py on the mercurial codebase
# HG changeset patch
# User Ludovic Chabant
# Date 1601415526 25200
# Tue Sep 29 14:38:46 2020 -0700
# Node ID 0b78eb21c79f02980e59ae30c6049075534b
# Parent f8726d166fcaa0d690f6783146172758b2e14deb
hgdemandimport: exclude more sqlalchemy modules
We could potentially exclude the entire
# HG changeset patch
# User Ludovic Chabant
# Date 1601413962 25200
# Tue Sep 29 14:12:42 2020 -0700
# Node ID f8726d166fcaa0d690f6783146172758b2e14deb
# Parent 80bf7b1ada15622ea45b8ecc5647404f5acb2905
hgweb: don't try to wrap mod_wsgi loggers
diff --git a/mercurial/utils/procutil.py b
> It might be better to test isinstance(stream, io.RawIOBase). If the stream
> is a RawIOBase, write() should return the number of bytes written.
I'm not super familiar with Python C/native extension code, but it doesn't look
to me like the mod_wsgi.Log type is inheriting from an io base class?
We are running into a weird python import error over on hg.sr.ht... see this
callstack:
https://paste.sr.ht/~sircmpwn/2f1855857494e1e4ee71b7dbd9ef4fca6b99be89
The fix is to force-import the offending type before we enable hgdemandimport:
from sqlalchemy.dialects.postgresql.base import
ludovicchabant created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.
REPOSITORY
rHG Mercurial
BRANCH
default
REVISION DETAIL
https://phab.mercurial-scm.org/D8272
AFFECTED FILES
mercurial/archival.py
CHANGE DETAILS
diff --git
ludovicchabant added a comment.
It does seem brittle to me to override some Python internal method anyway?
Can we get rid of this altogether?
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST ACTION
https://phab.mercurial-scm.org/D8272/new/
REVISION DETAIL
ludovicchabant created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D9135
AFFECTED FILES
.hgignore
doc/Makefile
doc/gendoc.py
doc/templates/cmdheader.txt
ludovicchabant created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D9134
AFFECTED FILES
mercurial/help.py
CHANGE DETAILS
diff --git a/mercurial/help.py
54 matches
Mail list logo