mirror of
https://github.com/AdaCore/git-hooks.git
synced 2026-02-12 12:43:11 -08:00
e536bf865a
This change is mostly a cleanup which simplifies a bit the iteration over the list of commits for which to perform the various checks, by having that information provided via an attribute whose name is very specific about the semantics of what to use that list for. This was motivated by an issue we discovered recently where we forgot to exclude some commits when calling the commit-extra-checker hook. This happened because, no matter how simple the algorithm for computing the list of commits to check was, that simple algorithm was duplicated in many places. This avoids that, in the hopes that this will prevent this same kind of issues again in the future. Another way to view the benefits of this cleanup is that this will help ensure consistency in terms of the list of commits to which the various checks are applied. Note that we could have logically split this patch into two steps, with the first step simply renaming the "added_commits" attribute into "new_commits_for_ref", and then a second step introducing the "commits_to_check" attribute. In the end, both are combined in a single commit because it seems easier to review every location where the "added_commits" attribute was used, and make sure from the context that the correct list of commits was chosen in each instance the "added_commits" list used to be referenced. Otherwise, it's harder to review the second commit adding the "commits_to_check" attribute, because the reviewer then has to audit the entire set of sources himself in order to make sure no spot was missed. No actual behavior change should result from this change, and therefore no test is being added. Change-Id: I93c206968800dc738d3ebe4f5424f9201875383b TN: T929-030
37 lines
1.4 KiB
Python
37 lines
1.4 KiB
Python
"""Branch updates root module."""
|
|
|
|
|
|
def branch_summary_of_changes_needed(new_commits_for_ref, lost_commits):
|
|
"""Return True iff the summary of changes is needed...
|
|
|
|
Assuming a branch update (in the general sense, meaning either
|
|
a creation, deletion or reference change), inspect the list
|
|
of added and lost commits, and return True iff the update
|
|
email should include a summary of changes.
|
|
|
|
PARAMETERS
|
|
new_commits_for_ref: A list of CommitInfo objects, corresponding to
|
|
the commits added to the reference being updated.
|
|
lost_commits: A list of CommitInfo objects, corresponding to
|
|
the commits lost after this update.
|
|
"""
|
|
# If some commits are no longer accessible from the new
|
|
# revision, definitely send the summary.
|
|
if lost_commits:
|
|
return True
|
|
|
|
# Send a summary if any of the commits was marked as "no email".
|
|
# Since the user is not going to see the commit email for those
|
|
# commits, it's good to send a summary email in order to have
|
|
# have a trace of that commit.
|
|
for commit in new_commits_for_ref:
|
|
if not commit.send_email_p:
|
|
return True
|
|
|
|
# The question was raised whether we should include the summary
|
|
# if one of the commits is a merge commit. At the moment,
|
|
# we do not see a reason why merge commits should be treated
|
|
# differently from other commits.
|
|
|
|
return False
|