Before this patch, some functions are wrapped in reposetup(), but this
causes redundant nested wrapping, if two ore more repositories enable
keyword extension (e.g. hgweb serves multiple repositories).
Now, there is no need to define these wrapper functions in
reposetup(), because previous patches made them not directly refer to
kwtemplater instanciated in reposetup().
This patch factors these wrapper functions out from reposetup(), and
uses them to wrap functions only at once at loading keyword extension.
Wrapper functions of keyword extension are defined in reposetup(),
because they refer to kwtemplater instantiated in reposetup().
This patch makes them obtain kwtemplater instance via repository at
runtime. For reviewability, this patch focuses on wrapper functions,
which handle generator.
This is a part of preparations for defining them statically.
Wrapper functions of keyword extension are defined in reposetup(),
because they refer to kwtemplater instantiated in reposetup().
This patch makes them obtain kwtemplater instance via repository at
runtime.
This is a part of preparations for defining them statically.
Wrapper functions of keyword extension are defined in reposetup(),
because they refer to kwtemplater instantiated in reposetup().
But these functions can be defined statically, if kwtemplater can be
obtained via repository at runtime.
This is a part of preparations for defining them statically.
To avoid cyclic reference, this patch makes kwtemplater use weakref to
refer related repository instance.
Before this patch, kwweb_skip doesn't restore kwtemplater.match after
wrapped webcommands. This suppresses keyword expansion at wrapped
webcommands.
Typical usecase of this issue is "file" webcommand after annotate,
changeset, filediff or so on.
To ensure kwtemplater.match=util.never while original webcommand
running, this patch makes kwweb_skip yield values returned by it,
because it returns generator object.
Before this patch, kwdiff doesn't restore kwtemplater.restrict after
invocation of wrapped patch.diff(). This suppresses keyword expansion
at subsequent filelog.read().
Typical usecase of this issue is "hg cat" after "hg diff" with command
server. In this case, kwtemplater.restrict=True is kept in command
server process even after "hg diff".
To ensure kwtemplater.restrict=True while original patch.diff()
running, this patch makes kwdiff() yield values returned by it,
because it returns generator object.
Strictly speaking, if filelog.read() is invoked before completely
evaluating the result of previous patch.diff(), keyword expansion is
still suppressed, because kwtemplater.restrict isn't restored yet.
But this fixing should be reasonable enough, because patch.diff() is
consumed immediately, AFAIK.
Previously, rebase assumes the following pattern:
rebase:
with transaction as tr: # top-level
...
tr.__close__ writes rebasestate
unlink('rebasestate')
However it's possible that "rebase" was called inside a transaction:
with transaction as tr1:
rebase:
with transaction as tr2: # not top-level
...
tr2.__close__ does not write rebasestate
unlink('rebasestate')
tr1.__close__ writes rebasestate
That leaves a rebasestate on disk incorrectly.
This patch adds "removefilegenerator" to notify transaction code that the
state file is no longer needed therefore fixes the issue.
Previously, we constructed a formatter from a specific template
topic. Then from show() we reached into the internals of the
formatter to resolve a template string to be used to construct
a changeset templater.
A downside to this approach was it limited us to having the
entire template defined in a single entry in the map file. You
couldn't reference other entries in the map file and this would
lead to long templates and redundancy in the map file.
This commit teaches @showview how to instantiate a changeset
templater so we can construct a templater with full access to
the map file. To prove it works, we've split "showwork" into
components.
This is one step towards removing a bunch of "if isinstance(gen,
unbundle20)" by treating bundle1 and bundle2 more similarly.
The name may sounds ironic for a method in the bundle2 module, but I
didn't think it was worth it yet to create a new 'bundle' module that
depends on the 'bundle2' module. Besides, we'll inline the method
again later.
Before this patch, -e/--edit and -e/--ssh of fetch command collide
against each other. This causes that -e is treated as shorthand of
--edit but doesn't work as same as --edit. Therefore, -e works as
neither --edit nor --ssh, in practice.
This issue was introduced at f54ee4b17f46 (or 1.0), which renamed
-f/--force-editor to -e/--edit. At that point, -e was already used as
shorthand of --ssh.
After this patch, -e is treated as shorthand of --ssh.
This patch is marked as "(BC)", because -e as shorthand of --edit in
existing scripts causes failure (or unexpected result) after this
patch. This impact should be less enough, because --edit mainly
focuses on interactive use.
BTW, test-duplicateoptions.py (since 1f980ef518d2 or 1.9) can't detect
this kind of issues as expected, because direct invocation of
extensions.loadall() doesn't involve registration of commands defined
in extensions (this issue is fixed in subsequent patch).
Earlier, on parsing the bullet points from existing release notes the bullet
points after the first one weren't written correctly to the notes file. This
patch makes changes to parsereleasenotesfromfile() function that introduces a new
bullet_points data structure that tracks the bullets and associated subparagraph.
It also makes necessary changes to the tests related to merging of bullets.
Since its introduction in c7ec460797a9, the parameter has always been name
"error". Yet the eol extension have been using 'haserror' as the argument name,
breaking extensions with subclass passing 'error' as a keyword argument.
Previously, there is a 100 changes limit per name (bookmark or named
branch). And the user will get "too many shelved changes named %s" when they
are trying to shelve the 101th change. I hit that error message today.
This limit was introduced by the shelve extension since the beginning.
The function generating the names was called "gennames", under
"getshelvename".
There is another "gennames" under "backupfilename":
def backupfilename(self):
def gennames(base):
yield base
base, ext = base.rsplit('.', 1)
for i in itertools.count(1):
yield '%s-%d.%s' % (base, i, ext)
"itertools.count" is an endless counter.
Since the other "gennames" generates unlimited number of names, and the
changeset introducing the limit (49d4919d21) does not say why the limit
is useful. It seems safe to just remove the limit.
The format "%02d" was kept intentionally so existing shelved changes won't
break.
This path is also used for extdiff, which is how I crossed paths with it.
Without this, an AttributeError occurs looking for 'lfstatus' on
localrepository. See also ca0085e432d6.
The other archive method is for the archival.py override, so it doesn't need to
be special cased like this. (It looks like it is only called for the top level
repo.) Likewise, the transplant override is also for commands.py. The other
overrides set lfstatus before examining it.
Since 1d07d9da84a0, pycompat.bytestr() wrapped by win32mbcs returns
unicode object, if an argument is not byte-str object. And this causes
unexpected failure at colorization.
pycompat.bytestr() is used to convert from color effect "int" value to
byte-str object in color module. Wrapped pycompat.bytestr() returns
unicode object for such "int" value, because it isn't byte-str.
If this returned unicode object is used to colorize non-ASCII byte-str
in cases below, UnicodeDecodeError is raised at an operation between
them.
- colorization uses "ansi" color mode, or
Even though this isn't default on Windows, user might use this
color mode for third party pager.
- ui.write() is buffered with labeled=True
Buffering causes "ansi" color mode internally, regardless of
actual color mode. With "win32" color mode, extra escape sequences
are omitted at writing data out.
For example, with "win32" color mode, "hg status" doesn't fail for
non-ASCII filenames, but "hg log" does for non-ASCII text, because
the latter implies buffered formatter.
There are many "color effect" value lines in color.py, and making them
byte-str objects isn't suitable for fixing on stable. In addition to
it, pycompat.bytestr will be used to get byte-str object from any
types other than int, too.
To resolve this issue, this patch does:
- replace pycompat.bytestr in checkwinfilename() with newly added
hook point util._filenamebytestr, and
- make win32mbcs reverse-wrap util._filenamebytestr
(this is a replacement of 1d07d9da84a0)
This patch does two things above at same time, because separately
applying the former change adds broken revision (from point of view of
win32mbcs) to stable branch.
"_" prefix is added to "filenamebytestr", because it is win32mbcs
specific hook point.
win32mbcs wraps some functions, to prevent them from unintentionally
treating backslash (0x5c), which is used as the second or later byte
of multi bytes characters by problematic encodings, as a path
component delimiter on Windows platform.
This wrapping assumes that wrapped functions can safely accept unicode
string arguments.
Unfortunately, 440868900036 broke this assumption by introducing
pycompat.bytestr() into util.checkwinfilename() for py3 support. After
that, wrapped checkwinfilename() always fails for non-ASCII filename
at pycompat.bytestr() invocation.
This patch wraps underlying pycompat.bytestr() function to use
util.checkwinfilename() safely.
To avoid similar regression in the future, another patch series will
add smoke testing on default branch.
I tripped on some weirdness relating to _thread vs threading way down
in a dep of highlight recently. I'm not really sure why I'm only just
seeing this defect now, but experimentally this fixes the problem, and
shouldn't cause any load-time slowness for people until pygments is
actually about to be used since highlight.highlight is still lazily
loaded in the highlight/__init__.py file.
There are some paragraphs, which aren't rendered in online help as
expected because of indentation and literal blocking issues.
- hgext/rebase.py
- paragraph before example code ends with ":", which treats
subsequent indented paragraphs as normal block
=> replace ":" with "::" to treat subsequent paragraphs as literal block
- help/pager.txt
- paragraph before a list of --pager option values ends with "::",
which treats subsequent indented paragraphs as literal block
=> replace "::" with ":" to treat subsequent paragraphs as normal block
- the second line of explanation for no/off --pager option value is
indented incorrectly (this also causes failure of "make" in doc)
=> indent correctly
- help/revisions.txt
- explanation following example code of "[revsetalias]" section
isn't suitable for literal block
=> un-indent explanation paragraph to treat it as normal block
- indentation of "For example" before example of tag() revset
predicate matching is meaningless
- descriptive text for tag() revset predicate matching isn't
suitable for literal block
=> un-indent concatenated two paragraphs to treat them as normal block
Durham and I both like this better than "underway." We can add aliases
and bikeshed on the name during the 4.3 cycle, as this whole extension is
highly experimental.
Previously, we'd rely on the implicit check that `localrepo.commit` did.
The problem is that that check only happened when the working copy was
dirty. With a "clean" working copy but unresolved conflicts we'd get
into a broken state.
To fix that, do what rebase does and check for unresolved conflicts at
the start of histedit --continue.
Previously, the --template/-T option didn't show up in help because it's marked
as experimental. It's not really experimental for show, and its quite important
for show's funcationality, so let's make sure it always shows up.
This is the beginning of a wip/smartlog view. It is basically a manually
constructed (read: fast) revset function to collect "relevant"
changesets combined with a custom template and a graph displayer.
It obviously needs a lot of work.
I'd like to get *something* usable in 4.2 so `hg show` has some value
to end-users.
Let the bikeshedding begin.
Because we're formatting to RST, short lines wrap and there
needs to be an extra line break between paragraphs to prevent
that.
In addition, the indentation in the old code was a bit off.
Refactor the code to a function (so we don't leak variables outside
the module) and modify it so it renders more correctly.
changeset_templater has lots of arguments, but most callers only need to
specify a literal template 'tmpl'.
"hg debugtemplate" has no diff option, which means 'opts' were effectively {},
so dropped opts.
