Summary: Mostly empty lines removed and added. A few bugfixes on excessive line splitting.
Reviewed By: quark-zju
Differential Revision: D8199128
fbshipit-source-id: 90c1616061bfd7cfbba0b75f03f89683340374d5
Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).
Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.
Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.
An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.
As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.
Reviewed By: wez, phillco, simpkins, pkaush, singhsrb
Differential Revision: D8173629
fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
This will help us in determining easily that whether fuzzywuzzy is loaded or not
loaded in any of the function.
Differential Revision: https://phab.mercurial-scm.org/D1120
While producing releasenotes for (4.3::), releasenotes aborts with error because
of some bad formatting of releasenotes in some commits. Instead of aborting,
this adds warning message which will help us in skipping them and telling user
about it.
Differential Revision: https://phab.mercurial-scm.org/D1097
If fuzzywuzzy is note present, we will not be having the capability to merge
existing releasenotes with the new releasenotes on the similarity basis.
The merging will still work good for exact same releasenotes entries.
Differential Revision: https://phab.mercurial-scm.org/D1096
The function document says that it returns true when the fragment can be merged,
but if you see the function just above it which is similar(), it writes already
exists thing if return value from similaritycheck() is False which is just
opposite of the doc. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1119
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
This patch adds documentation related to the two new flags --check and
--list for releasenotes extension.
Differential Revision: https://phab.mercurial-scm.org/D544
The releasenotes command is supposed to raise an error when --list and
--rev/--check flags are used together. This patch adds the above functionality.
Differential Revision: https://phab.mercurial-scm.org/D831
Since this extension is fairly new for almost all the contributors, remembering
the admonition (with titles) is difficult. The list (-l) flag provides
a list of all the active admonitions along with titles.
For usage, hg releasenotes -l returns the list.
Differential Revision: https://phab.mercurial-scm.org/D454
While using releasenotes extension, we will be using admonitions in commit messages.
The check (-c) flag will look for an admonition within the message. If it exists, it will
verify if it is stated under default or custom admonition. The check fails if the
admonition is not present in any of them. It also suggests similar admonitions
in case the admonition is invalid.
Differential Revision: https://phab.mercurial-scm.org/D368
It is possible that the incoming note fragments have some similar content as the
existing release notes. In case of a bug fix, we match for issueNNNN in the
existing notes. For other general cases, it makes use of fuzzywuzzy library to get
a similarity score. If the score is above a certain threshold, we ignore the
fragment, otherwise add it. But the score might be misleading for small commit
messages. So, it uses similarity function only if the length of string (in words)
is above a certain value. The patch adds tests related to its usage. But it needs
improvement in the sense of combining incoming notes. We can use interactive mode
for adding notes. Maybe we can do this if similarity is under a certain range.
By default, the extension has default sections like fix, feature, perf etc.. This
patch allow user to add support for custom admonition. In order to add a custom
admonition, one needs to have a .hgreleasenotes file inside the repository. All the
custom directive with name specified under the tag [sections] will be
usable by the extension. One important thing to keep in mind is if there exists any
custom admonitions with same key as default then they will override the default ones.
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.
Per discussion on the mailing list, we want better release notes
for Mercurial.
This patch introduces an extension that provides a command for
producing release notes files. Functionality is implemented
as an extension because it could be useful outside of the
Mercurial project and because there is some code (like rst
parsing) that already exists in Mercurial and it doesn't make
sense to reinvent the wheel.
The general idea with the extension is that changeset authors
declare release notes in commit messages using rst directives.
Periodically (such as at publishing or release time), a project
maintainer runs `hg releasenotes` to extract release notes
fragments from commit messages and format them to an auto-generated
release notes file. More details are explained inline in docstrings.
There are several things that need addressed before this is ready
for prime time:
* Moar tests
* Interactive merge mode
* Implement similarity detection for individual notes items
* Support customizing section names/titles
* Parsing improvements for bullet lists and paragraphs
* Document which rst primitives can be parsed
* Retain arbitrary content (e.g. header section/paragraphs)
from existing release notes file
* Better error messages (line numbers, hints, etc)