This commit enhances the commit emails we sent for Git Notes updates.
The goal is to include the names of the branches that contain the
annotated commit, similar to how we include the name of the branch
for regular commit emails, implemented in a way that this feature
covers all references, rather than just all branches (some projects
have branches under a non-standard namespace).
In summary, notes commit emails have their subject changed from...
[notes][repo] annotated commit subject
... to...
[notes][repo/branch1,branch2] annotated commit subject
Note that, if only one branch contains the annotated commit,
and that branch name is "master", then the subject remains
unchanged. This follows a practice we already have for regular
commit emails.
This commit also introduces a new config option called
max-ref-names-in-subject-prefix, which controls how many
such branch/reference names we include in the subject,
to avoid making that subject too long.
The full list of branches/references containing the annotated
commit is also included, unabridged, at the start of the "Diff:"
section.
Change-Id: I61ef0c497862f1243d3435a429120d63a27e4b3b
TN: S731-057
Now that Python 3.x is required, this import is no longer useful.
Note that this commit deliberately excludes the imports done
in the testsuite, so as to allow these changes to be reviewed
independently of the changes to be made in the testsuite.
Change-Id: I28e1857df2cf0b2f9e7ddeab00b456d6ef513755
TN: U530-006
Other than pure convenience (and the fact that it allows callers
to not have to pass the ref_name each time it is called), there was
no real reason why this code needs to be defined as a method of
the AbstractUpdate class. This commit moves the code to a function
in the utils module, so as to allow it to be called from outside
the AbstractUpdate class hierachry, something we'll want to do
in an upcoming commit.
We still keep the search_config_option_list method for the convenience
it brings to the existing callers, but its implementation is simplified
to call the new function in utils instead.
Change-Id: Ie2e1f192da8522471c42910283a9c1f482daf6b0
TN: UA21-052
This commit updates the pre-commit hook to black version 21.5b1.
The hooks where then re-run on all files to update their formatting
to this new version of black.
Change-Id: Ib0866745ef8432cf93380a4d83fa23a479eb4a49
This commit replaces the litteral number "0664", which is no longer
valid syntax in Python 3.x, with "0o664", which is valid with both
Python 2.x and Python 3.x.
This is good preparation for the transition to Python 3.x, and
this also makes sure the current version of this module now passes
AdaCore's internal style checker.
Change-Id: I43ea77e894d8abbf8b36dfd40da2b8a4856489fd
In preparation for the transition to Python 3, convert to using the
print function. The special import
from __future__ import print_function
in Python 2.7 makes "print" become the function and not the statement.
In Python 3, it has no effect. Once the transition is done and we
exclusively use Python 3, we can simply remove the imports.
The testsuite shows no regressions.
This commit introduces a new class (ThirdPartyHook), which centralizes
the handling of third-party hooks (scripts that project set up via
the configuration file). Most of the code is simply a move of the code
from maybe_call_thirdparty_hook, with a couple of enhancements:
- Ability to specify the directory from which to call the hook;
- Handling of the situation when calling the hook itself fails.
We can already see the benefits of this in function style_check_files,
where the code now necessary to call the style_checker is both clearer
and more compact.
In the future, the intent is to push this class one step further to
allow users to specify hooks to be fetched from the repository, rather
than requiring that the hooks be installed (usually by an admin) on
the machine hosting the repository. The current class' API should
allow us to implement this in a way that's transparent to all users.
Change-Id: Ie8bf8accbbfd75a91b914628fad27d780532dac4
TN: T209-005
In other words, if you have a repository is configured with:
[hooks]
no-emails = refs/heads/master
The "hooks.no-emails" configuration should only apply to the master
branch, not any branch whose name happens to start with "master".
Incidentally, fixing this problem uncovered an error in the configuration
in the repository used in one of the testcases. This commit fixes that
error.
Change-Id: Ic3cdc56e4122fae65bbec792e12a002f2042b7e3
TN: T622-001
This option allows users to specify a script to be run at update time,
for each reference being updated. This script can then be used to perform
additional checks on top of the standard checks already provided by
our git-hooks.
Change-Id: Iff527f1c9c0ba516ea5181c5f8c066c5175ef0ee
TN: T209-001
Not sure why, but trying to create sockets on some machines triggered
an error, maybe because of insufficient privileges or unportable
socket usage. As a result, all pushes were systematically rejected,
with the hooks thinking that they had detected a concurrent push
request.
This patch re-implement the locking mechanism using a filesystem-based
approach (hard links).
For M903-031.
Make the space between the prefix and each list of the contents
of the warning completly explicit. That way, if a caller wants
no prefix, the function does not generate a leading space on
every line printed.
The fact that utils.py imports config.py makes it difficult for
config.py to access the InvalidUpdate exception. So move this
exception to its own package, free of dependencies.
Preparation work for LC27-007.
For future additions to these scripts, there are some traces that
are only useful some times, and are otherwise a potential source
of a lot of noice (traces generated for each change in a given commit,
for instance). For this purpose, we introduce the notion of debug
level.
To reflect this change, the name of the environment variable and
git config variable has been changed to HOOKS_DEBUG_LEVEL and
hooks.debuglevel accordingly.
