This is a followup on T227-003, where we enhanced the hooks to take
refs/meta/config updates into account right away. A small side-effect
of that change is that the error message when trying to delete the
refs/meta/config reference changed from...
| This type of update (refs/meta/config,delete) is currently unsupported
... to ...
| Unable to find the file project.config in refs/meta/config.
|
| Your repository appears to be incorrectly set up. Please contact
| your repository's administrator to set your project.config file up.
The former wasn't all that great, but understandable. The new one
is not incorrect, but not very helpful. This patch therefore enhances
the hooks to provide a clear error message:
| Deleting the reference refs/meta/config is not allowed.
|
| This reference provides important configuration information
| and thus must not be deleted.
A new testcase is added to make sure we continue verifying
the error message in that situation.
Change-Id: I5178b40c0d003fbf8ffeb456592750ec38a9a047
This commit enhances the hooks to read the repository's configuration
from the most recent version. In particular, if an update is updating
the refs/meta/config reference, then read the configuration from that
update, instead of reading from the existing refs/meta/config reference.
For updates of all other references, the behavior remains unchanged.
A testcase (T227-003__meta_config_is_immediate) is added to verify
that refs/meta/config reference creation works as expected.
Following that change, various testcases also needed to be adapted
as follow:
- MC27-006__meta_config_branch_create: Creating the refs/meta/config
reference now works;
- QC13-022__checker_config_on_its_own: This testcase was pushing
a local branch called "meta-config" to refs/meta/config. This
update introduced a style-checker-config-file configuration. Since
the configuration is now taken into account right away, the update
is was rejected due to the file not existing.
The branch "meta-config" is renamed to "meta-config-missing",
and a new branch "meta-config" was created, containg the missing
file in addition to the configuration changes above.
We first try to push the "meta-config-missing" to verify
that this is rejected. We then try to push the (new) "meta-config"
branch, verifying that the presence of the config file allows
the push to be accepted.
- T209-001__update_hook_not_found: A similar situation to the above,
but with the update hook. The added comments in the testcase
should make the changes self-explanatory.
- T209-001__update_hook_reject: Modify the update-hook, which is
called during reference updates, to not reject the refs/meta/config
update the testcase is doing as part of the preliminary setup phase.
Change-Id: I0bd7bc0801ba08cd281a751759bba8c48ba0c454
TN: T227-003
When initially created, these hooks were reading the repository's
configuration from an untracked file, installed in the repository.
In December 2013, this method of configuring the hooks became obsolete,
in favor of getting the information from a file which is checked in.
However, to ease the transition, support for the untracked config
file was kept as a fallback, with a large warning asking the user
to contact the repository's admin to perform the transition.
At this point, it is believed that all repositories have now
transitioned, and therefore keeping this fallback is no longer
necessary.
This commit therefore removes support for that functionality.
A couple of testcases are adjusted accordingly. As a side-effect,
this caused the testing of branch creations for branches whose name
does not follow the standard naming scheme to no longer be tested.
This commit therefore adds one using a reference name which is not
refs/meta/config, thus ensuring that testing coverage remains at 100%.
Change-Id: I3e9c176f46e831ea82cdc930d32f7f22913a4fbc
TN: T314-004
The main purpose of that pre-receive hook is to ensure that any push
updating the refs/meta/config reference only updates that one reference.
A large comment was added to the code to explain why (in short, this is
a pre-requisite for being able to use the git-hooks config at the same
time the config changes are being pushed).
While at it, to be consistent with the other hooks, support for
a repository-specific pre-receive hook is added. One side-effect
of this is that we end up trying to query the hooks configuration,
which triggers a check for the existence of the refs/meta/config
branch. As a result, an extra copy of the same warning gets generated
when the reference doesn't exist. This is not super elegant, but
isn't a problem in practice, since this is part of handling a deprecated
feature that we'll try to remove support for hopefully soon. In the
meantime, this isn't blocking to adding support for the pre-receive
option.
Since this commit increased the number of times `refs/meta/config`
was spelled out (aka "hardcoded"), this commit introduces a new
constant to avoid duplicating that special reference name.
Change-Id: Ib4fc0a32f639fe693e4d43269baf8c0838fc9214
TN: T227-003
This commit is only there to simplify the logic behind handing
the data passed when calling the post_receive.py script. In particular,
this script receives information:
- via the command-line, with the optional --submitter-email option;
- via stdin, with one line per reference being updated.
I don't know what I was thinking at the time, but somehow, the way
I chose to handle this was by appending to each entry from stdin
the arguments from the command-line, and then use an ArgumentParser
to pass each stdin entry. It works, but in practice, the it makes
the code more difficult to understand. In fact, when I read this code
again recently, I missed the tiny "+ sys.argv[1:]" and so it made me
(wrongly) believe that the command-line arguments were entirely ignored!
So, this commit simplifies this by clearly separating the phase
of parsing the command-line, and the phase of processing each
entry passed via stdin by git.
Change-Id: I2e01a99e7c1931a56e9b95f196a2f73f9be70a2e
TN: T223-004
This commit rewrites some code that was building a poor-man's version
of an enum type by an enum.Enum subclass. No functional change.
Seen while working on T209-003 (allowing custom ref naming)
Change-Id: I5dbe9b69a421c980b98f52896b6048d53dc1f764
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
Just import the one symbol that's actually used by the various
testcases in its place. This allows us to pass all current
style checks at AdaCore for Python files.
Change-Id: I458060771e18684e097e98131f292e09690a2e6d
Add a comment in the function implementing this feature explaining
the reason behind the choices made for that email.
Change-Id: I267f52ea651218b461e3d6c3c79882b887184c9b
TN: T209-007
This lifts a limitation where non-fast-forward updates could only be
allowed for references whose name start with 'refs/heads/' (the
standard namespace for branches). As it happens, GCC is using branch
names in a different namespace. So this commit changes this config
option to match the entire reference name, rather than just the branch
name. There is a break in compatibility for the repositories already
using this configuration, but this change takes care of detecting
this situation and provide an informative message explaining the likely
situation.
Change-Id: I330d15ccef448e815c94a620f008275f1e1914db
TN: T209-002
When a test wants to verify the output of a given command, it normally
does this as follow:
self.assertRunOutputEqual(p, expected_out)
What this does is verify that the command's output matches, and if it
does not, then it not only reports and error, but also provides a diff
at the end, so as to facilitate the analysis.
However, while writing a test where that was unexpected failing
an output comparison, the diff in the error message was empty.
After investigation, it turned out that the function used to compute
that diff has a parameter ignore_white_chars set to True, which is
not what we want, here, and explains the discrepancy.
This commit fixes that by explicitly setting that parameter to False.
In the situation described above, this allowed the difference to
be shown in the diff section.
Change-Id: Ie5df10bcd7990eab928fc6f7fed3f41eaaa5d469
This line of code was highlighted as uncovered by the testsuite's
coverage analysis, and reveals that we never call this method with
a CommitInfo object whose `parent_revs' attribute is None.
This attribute is first set during the class's initialization
(__init__) to the value of the parameter of the same name. And
the reason why we check for None here is because the __init__
routine documents this paramenter as allowing None, signifying
that the actual value hasn't been computed yet. The purpose of
this is to allow users who know that they don't need the parents
to skip computing them just for the sake of creating an object
of this class.
Upon investigation, it turns out that the only place where objects
of this class are instantiated is in function commit_info_list, where
the list of parents is actually computed and provided to the class.
This shows that, as of today, this uncovered code is actually
unreachable.
There were several options:
(a) It is conceivable that some callers might find it useful
that the parents get automagically computed on demand,
arguing in favor of keeping that code. If we keep the code,
we can cover it via Unit Testing.
(b) Document that the instantiators of this class must always
provide the list of parents at instantiation, thus making
the check for None moot, allowing us to simply remove it.
(c) Continue to allow the use of None for the list of parents,
but still removing the code, transfering the responsibility
to the users to be sure that it is not None before calling it.
In the end, it felt better to follow what is true today rather than
what "might be" tomorrow, so this commit rejects option (a).
Option (b) is simplest, but has the drawback of reducing flexibility
in terms of performance tweaking. This is why this commit chose
option (c), especially since it's trivial for users to handle this,
as it's just a matter of calling one function.
Change-Id: I3a01ab52c06ae36f249e0c01fbc7ea59616e6ded
The testsuite depends on git running with default configuration.
Customizations in the user's global configuration ($HOME/.gitconfig)
should be ignored.
Change-Id: Iff4b3ba49294fd78bb1d5a78a908a9308ae0b5d8
Include original commit name and note ref name (if not default)
in subject.
Minor wording tweaks.
for S724-027
Change-Id: I9660c19876627c1259e9b7a42ea7b2f9f9669f43
There was a bug when returning an error message indicating that
the revision contains non-ISO-8859-15, that would always show
the first line has having the unwanted character, even when
that characters was actually on a different line.
And while at it, I improved the error message to include the line
number as well. Just in case showing the text itself is either not
sufficient or just not as efficient.
Credit for finding the bug: Thomas Quinot (thank you!).
Followup on QB25-001.
