I was just going through the module and noticed the typo. This commit
fixes 'onfalure' -> 'onfailure'.
Differential Revision: https://phab.mercurial-scm.org/D906
This is to prevent weird surprises from happening with skips being attributed
to the wrong changeset.
.. feature::
`hg annotate --skip` now prints a `*` on lines with skipped revisions
Differential Revision: https://phab.mercurial-scm.org/D900
We're going to extend this a bit -- at first by simply adding whether this was
a skipped child. We're well on our way to outgrowing tuples, though -- adding
more and more fields to tuples becomes annoying very quickly.
Differential Revision: https://phab.mercurial-scm.org/D898
In the next diff we're going to import mercurial.thirdparty.attr, and pyflakes
complains about this if this rename isn't done.
Differential Revision: https://phab.mercurial-scm.org/D897
In upcoming patches the output is going to be significantly longer than it is
today, and doctests don't allow wrapping the output.
Differential Revision: https://phab.mercurial-scm.org/D896
unittest has a `maxDiff` parameter which has to be set to `None` in order for
large enough failure diffs to be displayed. Add a comment to disable the
camelcase check for `self.maxDiff = None` lines.
Differential Revision: https://phab.mercurial-scm.org/D895
We only ever call these functions in a single way, so let's just
actually specify them. We need to do some string/bytes encoding
dancing here for Python 3, so it'll help to know what arguments we
need to convert.
# no-check-commit because I'm modifying functions that check-commit
does not like.
Differential Revision: https://phab.mercurial-scm.org/D885
Before, _hybrid.gen must be a generator which could be consumed only once.
It was okay in templatekw.py since template keywords are functions which
create temporary hybrid objects, but the formatter doesn't work in that way.
To work around the issue, this patch makes _hybrid.gen optionally be a
function returning a generator.
Thanks to Pulkit for finding this issue.
Store in effect flag when the diff changed between the predecessor and
its successors.
Comparing the diff is not easy because we do not want to incorrectly detect a
Store in effect flag when the meta changed between the predecessor and its
successors. We blacklisted some known meta that would always changed when
another flag change. For example rebase would always add a meta rebase-source
while the effect flag parents will already detect this situation.
It can happens with various hg commands.
Differential Revision: https://phab.mercurial-scm.org/D540
Store in effect flag when the parents changed between the predecessor and
its successors.
It can happens with "hg rebase" or "hg grab".
Differential Revision: https://phab.mercurial-scm.org/D539
Store in effect flag when the branch changed between the predecessor and
its successors.
It can happens with "hg branch" + "hg commit --amend", "hg branch" + "hg
amend" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D538
Store in effect flag when the date changed between the predecessor and
its successors.
It can happens with "hg commit --amend -d", "hg amend -d" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D537
Store in effect flag when the user changed between the predecessor and its
successors.
It can happens with "hg commit --amend -u" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D536
Store in effect flag when the description changed between the predecessor and
its successors.
It can happens with "hg commit --amend -e", "hg amend -e" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D535
Add all the tests in this patch, it makes the patch quite big but will clarify
the following patches impact on tests.
Differential Revision: https://phab.mercurial-scm.org/D534
The idea behind effect flag is to store additional information in obs-markers
about what changed between a changeset and its successor(s). It's a low-level
information that comes without guarantees.
This information can be computed a posteriori, but only if we have all
changesets locally. This is not the case with distributed workflows where you
work with several people or on several computers (eg: laptop + build server).
Storing the effect-flag as a bitfield has several advantages:
- It's compact, we are using one byte per obs-marker at most for the effect-
flag.
- It's compoundable, the obsfate log approach needs to display evolve history
that could spans several obs-markers. Computing the effect-flag between a
changeset and its grand-grand-grand-successor is simple thanks to the
bitfield.
The effect-flag design has also some limitations:
- Evolving a changeset and reverting these changes just after would lead to
two obs-markers with the same effect-flag without information that the first
and third changesets are the same.
The effect-flag current design is a trade-off between compactness and
usefulness.
Storing this information helps commands to display a more complete and
understandable evolve history. For example, obslog (an Evolve command) use it
to improve its output:
x 62206adfd571 (34302) obscache: skip updating outdated obscache...
| rewritten(parent) by Matthieu Laneuville <matthieu.laneuville@octobus...
| rewritten(content) by Boris Feld <boris.feld@octobus.net>
The effect flag is stored in obs-markers metadata while we iterate on the
information we want to store. We plan to extend the existing obsmarkers
bit-field when the effect flag design will be stabilized.
It's different from the CommitCustody concept, effect-flag are not signed and
can be forged. It's also different from the operation metadata as the command
name (for example: amend) could alter a changeset in different ways (changing
the content with hg amend, changing the description with hg amend -e, changing
the user with hg amend -U). Also it's compatible with every custom command
that writes obs-markers without needing to be updated.
The effect-flag is placed behind an experimental flag set to off by default.
Hook the saving of effect flag in create markers, but store only an empty one
for the moment, I will refine the values in effect flag in following patches.
For more information, see:
https://www.mercurial-scm.org/wiki/ChangesetEvolutionDevel#Record_types_of_operation
Differential Revision: https://phab.mercurial-scm.org/D533
Various mutators fail when attempting to write obsmarkers with
metadata fields longer than 255 bytes, since the length of
mwetadata fields is stored in u8s. This change raises a more
helpful error in such circumstances.
Differential Revision: https://phab.mercurial-scm.org/D865
This location is used by debian (and ubuntu) to store completions provided by
other deb packages. The default fpath appears to have this before any of the
zsh-provided instances of the completions, so this should take precedence.
Differential Revision: https://phab.mercurial-scm.org/D882
If the filename is not specified while using --rev, the notes for the specified
revs will just be displayed on screen.
Differential Revision: https://phab.mercurial-scm.org/D877
The attrs package allows defining namedtuple-like classes with no weird
behavior and no runtime performance cost.
This patch vendors in attrs 17.2.0.
# no-check-commit
Differential Revision: https://phab.mercurial-scm.org/D867
--uncompressed isn't a very good name and its description in the
help documentation isn't very useful. We refer to this concept as
"stream clones" in a number of places. I think it makes sense to
change the user-facing argument to use the mode --stream. So this
commit does that.
We keep --uncompressed around for backwards compatibility.
While we're here, we overhaul the help docs for streaming clones
to be somewhat useful.
All tests have been updated to reflect the new preferred --stream
argument. A test for backwards compatibility of --uncompressed has
been added.
.. bc::
`hg clone --stream` should now be used instead of --uncompressed.
--uncompressed is marked as deprecated and is an alias for --stream.
There is no schedule for elimination of --uncompressed.
Differential Revision: https://phab.mercurial-scm.org/D864
This was added in 021454637716 in 2006. This may be possible but it
seems like a bad idea to even suggest it.
Differential Revision: https://phab.mercurial-scm.org/D863
Building on top of the new URL query string arguments to control
whitespace settings for annotate, this commit adds HTML checkboxes
reflecting the values of these arguments to the paper and gitweb
themes.
The actual diff settings are now exported to the templating layer.
The HTML templates add these as data-* attributes so they are
accessible to the DOM.
A new <form> with various <input> elements is added. The <form>
is initially hidden via CSS. A shared JavaScript function (which
runs after the <form> has been rendered but before the annotate
HTML (because annotate HTML could take a while to load and we want
the form to render quickly) takes care of setting the checked state
of each box from the data-* attributes. It also registers an event
handler to modify the URL and refresh the page whenever the checkbox
state is changed.
I'm using the URLSearchParams interface to perform URL manipulation.
https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams tells
me this may not be supported on older web browsers. Yes, apparently
the web API didn't have a standard API to parse and format query
strings until recently. Hence the check for the presence of this
feature in the JavaScript. If the browser doesn't support the
feature, the <form> will remain hidden and behavior will like it
currently is. We could polyfill this feature or implement our own
query string parsing. But I'm lazy and this could be done as a
follow-up if people miss it.
We could certainly expand this feature to support more diff options
(such as lines of context). That's why the potentially reusable code
is stored in a reusable place. It is also certainly possible to
add diff controls to other pages that display diffs. But since
Mozillians are making noise about controlling which revisions
annotate shows, I figured I'd start there.
.. feature::
Control whitespace settings for annotation on hgweb
/annotate URLs on hgweb now accept query string arguments to
influence how whitespace changes impact results.
The arguments "ignorews," "ignorewsamount," "ignorewseol," and
"ignoreblanklines" now have the same meaning as their [annotate]
config section counterparts. Any provided setting overrides the
server default.
HTML checkboxes have been added to the paper and gitweb themes
to expose current whitespace settings and to easily modify the
current view.
Differential Revision: https://phab.mercurial-scm.org/D850
This feature should hopefully be pretty straightforward. We simply
examine some query string arguments to feed into the diff options.
The function to obtain the diff options has been factored into its
own generic function to facilitate an upcoming change to the HTML
interface and to enable diff settings to be controlled via the same
query string arguments on other web commands.
The test output for "ignoreblanklines" didn't change. I'm not sure
why. Our test coverage for --ignore-blank-lines isn't great and I
can't figure out how to make this diff setting do anything meaningful.
On a very brief examination of the code, it is possible the setting
doesn't work because it is operating at the line level and blank lines
detection needs to examine multiple lines. But I'm not an expert in
this code, so I'm not sure.
Differential Revision: https://phab.mercurial-scm.org/D849
I will add another experiment in createmarkers, add a comment and some blank
lines for aesthetic sake.
Differential Revision: https://phab.mercurial-scm.org/D532
