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.
Prior to this the return value was potentially None, a string, or a
list of strings. It now always returns a list of strings where each
string is always only one email address
watchman's paths encoding can differ from filesystem encoding. For example,
on Windows, it's always utf-8.
Before this patch, on Windows, mismatch in path comparison between fsmonitor
state and osutil.statfiles would yield a clean status for added/modified files.
In addition to status reporting wrong results, this leads to files being
discarded from changesets while doing history editing operations such as rebase.
Benchmark:
There is a little overhead at module import:
python -m timeit "import hgext.fsmonitor"
Windows before patch: 1000000 loops, best of 3: 0.563 usec per loop
Windows after patch: 1000000 loops, best of 3: 0.583 usec per loop
Linx before patch: 1000000 loops, best of 3: 0.579 usec per loop
Linux after patch: 1000000 loops, best of 3: 0.588 usec per loop
10000 calls to _watchmantofsencoding:
python -m timeit -s "from hgext.fsmonitor import _watchmantofsencoding, _fixencoding" "fname = '/path/to/file'" "for i in range(10000):" " if _fixencoding: fname = _watchmantofsencoding(fname)"
Windows (_fixencoding is True): 100 loops, best of 3: 19.5 msec per loop
Linux (_fixencoding is False): 100 loops, best of 3: 3.08 msec per loop
Mixing bytes and unicode creates a mess. Do things in bytes as possible.
New sysbytes() helper only takes care of ASCII characters, but avoids raising
nasty unicode exception. This is the same design principle as sysstr().
Currently, Mercurial has a number of commands to show information. And,
there are features coming down the pipe that will introduce more
commands for showing information.
Currently, when introducing a new class of data or a view that we
wish to expose to the user, the strategy is to introduce a new command
or overload an existing command, sometimes both. For example, there is
a desire to formalize the wip/smartlog/underway/mine functionality that
many have devised. There is also a desire to introduce a "topics"
concept. Others would like views of "the current stack." In the
current model, we'd need a new command for wip/smartlog/etc (that
behaves a lot like a pre-defined alias of `hg log`). For topics,
we'd likely overload `hg topic[s]` to both display and manipulate
topics.
Adding new commands for every pre-defined query doesn't scale well
and pollutes `hg help`. Overloading commands to perform read-only and
write operations is arguably an UX anti-pattern: while having all
functionality for a given concept in one command is nice, having a
single command doing multiple discrete operations is not. Furthermore,
a user may be surprised that a command they thought was read-only
actually changes something.
We discussed this at the Mercurial 4.0 Sprint in Paris and decided that
having a single command where we could hang pre-defined views of
various data would be a good idea. Having such a command would:
* Help prevent an explosion of new query-related commands
* Create a clear separation between read and write operations
(mitigates footguns)
* Avoids overloading the meaning of commands that manipulate data
(bookmark, tag, branch, etc) (while we can't take away the
existing behavior for BC reasons, we now won't introduce this
behavior on new commands)
* Allows users to discover informational views more easily by
aggregating them in a single location
* Lowers the barrier to creating the new views (since the barrier
to creating a top-level command is relatively high)
So, this commit introduces the `hg show` command via the "show"
extension. This command accepts a positional argument of the
"view" to show. New views can be registered with a decorator. To
prove it works, we implement the "bookmarks" view, which shows a
table of bookmarks and their associated nodes.
We introduce a new style to hold everything used by `hg show`.
For our initial bookmarks view, the output varies from `hg bookmarks`:
* Padding is performed in the template itself as opposed to Python
* Revision integers are not shown
* shortest() is used to display a 5 character node by default (as
opposed to static 12 characters)
I chose to implement the "bookmarks" view first because it is simple
and shouldn't invite too much bikeshedding that detracts from the
evaluation of `hg show` itself. But there is an important point
to consider: we now have 2 ways to show a list of bookmarks. I'm not
a fan of introducing multiple ways to do very similar things. So it
might be worth discussing how we wish to tackle this issue for
bookmarks, tags, branches, MQ series, etc.
I also made the choice of explicitly declaring the default show
template not part of the standard BC guarantees. History has shown
that we make mistakes and poor choices with output formatting but
can't fix these mistakes later because random tools are parsing
output and we don't want to break these tools. Optimizing for human
consumption is one of my goals for `hg show`. So, by not covering
the formatting as part of BC, the barrier to future change is much
lower and humans benefit.
There are some improvements that can be made to formatting. For
example, we don't yet use label() in the templates. We obviously
want this for color. But I'm not sure if we should reuse the existing
log.* labels or invent new ones. I figure we can punt that to a
follow-up.
At the aforementioned Sprint, we discussed and discarded various
alternatives to `hg show`.
We considered making `hg log <view>` perform this behavior. The main
reason we can't do this is because a positional argument to `hg log`
can be a file path and if there is a conflict between a path name and
a view name, behavior is ambiguous. We could have introduced
`hg log --view` or similar, but we felt that required too much typing
(we don't want to require a command flag to show a view) and wasn't
very discoverable. Furthermore, `hg log` is optimized for showing
changelog data and there are things that `hg display` could display
that aren't changelog centric.
There were concerns about using "show" as the command name.
Some users already have a "show" alias that is similar to `hg export`.
There were also concerns that Git users adapted to `git show` would
be confused by `hg show`'s different behavior. The main difference
here is `git show` prints an `hg export` like view of the current
commit by default and `hg show` requires an argument. `git show`
can also display any Git object. `git show` does not support
displaying more complex views: just single objects. If we
implemented `hg show <hash>` or `hg show <identifier>`, `hg show`
would be a superset of `git show`. Although, I'm hesitant to do that
at this time because I view `hg show` as a higher-level querying
command and there are namespace collisions between valid identifiers
and registered views.
There is also a prefix collision with `hg showconfig`, which is an
alias of `hg config`.
We also considered `hg view`, but that is already used by the "hgk"
extension.
`hg display` was also proposed at one point. It has a prefix collision
with `hg diff`. General consensus was "show" or "view" are the best
verbs. And since "view" was taken, "show" was chosen.
There are a number of inline TODOs in this patch. Some of these
represent decisions yet to be made. Others represent features
requiring non-trivial complexity. Rather than bloat the patch or
invite additional bikeshedding, I figured I'd document future
enhancements via TODO so we can get a minimal implmentation landed.
Something is better than nothing.
BTW, C implementation of hexdigest() for SHA-1/256/512 returns hex
hash in lower case, and doctest in Python standard hashlib assumes
that, too. But it isn't explicitly described in API document or so.
Therefore, we can't assume that hexdigest() always returns hex hash in
lower case, for any hash algorithms, on any Python runtimes and
versions.
From point of view of that, it is reasonable for portability that
77f8c025a6ef applies lower() on hex hash in overridefilemerge().
But on the other hand, in largefiles extension, there are still many
code paths comparing between hex hashes or storing hex hash into
standin file, without lower().
Switching to hash algorithm other than SHA-1 may be good chance to
clarify our policy about hexdigest()-ed hash value string.
- assume that hexdigest() always returns hex hash in lower case, or
- apply lower() on hex hash in appropriate layers to ensure
lower-case-ness of it for portability
