u-boot-brain/tools/patman/commit.py

110 lines
3.3 KiB
Python
Raw Permalink Normal View History

# SPDX-License-Identifier: GPL-2.0+
# Copyright (c) 2011 The Chromium OS Authors.
#
import collections
import re
# Separates a tag: at the beginning of the subject from the rest of it
re_subject_tag = re.compile('([^:\s]*):\s*(.*)')
class Commit:
"""Holds information about a single commit/patch in the series.
Args:
hash: Commit hash (as a string)
Variables:
hash: Commit hash
subject: Subject line
tags: List of maintainer tag strings
changes: Dict containing a list of changes (single line strings).
The dict is indexed by change version (an integer)
cc_list: List of people to aliases/emails to cc on this commit
notes: List of lines in the commit (not series) notes
patman: Use the Change-Id, version, and prefix in the Message-Id As per the centithread on ksummit-discuss [1], there are folks who feel that if a Change-Id is present in a developer's local commit that said Change-Id could be interesting to include in upstream posts. Specifically if two commits are posted with the same Change-Id there's a reasonable chance that they are either the same commit or a newer version of the same commit. Specifically this is because that's how gerrit has trained people to work. There is much angst about Change-Id in upstream Linux, but one thing that seems safe and non-controversial is to include the Change-Id as part of the string of crud that makes up a Message-Id. Let's give that a try. In theory (if there is enough adoption) this could help a tool more reliably find various versions of a commit. This actually might work pretty well for U-Boot where (I believe) quite a number of developers use patman, so there could be critical mass (assuming that enough of these people also use a git hook that adds Change-Id to their commits). I was able to find this git hook by searching for "gerrit change id git hook" in my favorite search engine. In theory one could imagine something like this could be integrated into other tools, possibly even git-send-email. Getting it into patman seems like a sane first step, though. NOTE: this patch is being posted using a patman containing this patch, so you should be able to see the Message-Id of this patch and see that it contains my local Change-Id, which ends in 2b9 if you want to check. [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html Signed-off-by: Douglas Anderson <dianders@chromium.org>
2019-09-28 01:23:56 +09:00
change_id: the Change-Id: tag that was stripped from this commit
and can be used to generate the Message-Id.
rtags: Response tags (e.g. Reviewed-by) collected by the commit, dict:
key: rtag type (e.g. 'Reviewed-by')
value: Set of people who gave that rtag, each a name/email string
warn: List of warnings for this commit, each a str
"""
def __init__(self, hash):
self.hash = hash
self.subject = None
self.tags = []
self.changes = {}
self.cc_list = []
self.signoff_set = set()
self.notes = []
patman: Use the Change-Id, version, and prefix in the Message-Id As per the centithread on ksummit-discuss [1], there are folks who feel that if a Change-Id is present in a developer's local commit that said Change-Id could be interesting to include in upstream posts. Specifically if two commits are posted with the same Change-Id there's a reasonable chance that they are either the same commit or a newer version of the same commit. Specifically this is because that's how gerrit has trained people to work. There is much angst about Change-Id in upstream Linux, but one thing that seems safe and non-controversial is to include the Change-Id as part of the string of crud that makes up a Message-Id. Let's give that a try. In theory (if there is enough adoption) this could help a tool more reliably find various versions of a commit. This actually might work pretty well for U-Boot where (I believe) quite a number of developers use patman, so there could be critical mass (assuming that enough of these people also use a git hook that adds Change-Id to their commits). I was able to find this git hook by searching for "gerrit change id git hook" in my favorite search engine. In theory one could imagine something like this could be integrated into other tools, possibly even git-send-email. Getting it into patman seems like a sane first step, though. NOTE: this patch is being posted using a patman containing this patch, so you should be able to see the Message-Id of this patch and see that it contains my local Change-Id, which ends in 2b9 if you want to check. [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html Signed-off-by: Douglas Anderson <dianders@chromium.org>
2019-09-28 01:23:56 +09:00
self.change_id = None
self.rtags = collections.defaultdict(set)
self.warn = []
def __str__(self):
return self.subject
def AddChange(self, version, info):
"""Add a new change line to the change list for a version.
Args:
version: Patch set version (integer: 1, 2, 3)
info: Description of change in this version
"""
if not self.changes.get(version):
self.changes[version] = []
self.changes[version].append(info)
def CheckTags(self):
"""Create a list of subject tags in the commit
Subject tags look like this:
propounder: fort: Change the widget to propound correctly
Here the tags are propounder and fort. Multiple tags are supported.
The list is updated in self.tag.
Returns:
None if ok, else the name of a tag with no email alias
"""
str = self.subject
m = True
while m:
m = re_subject_tag.match(str)
if m:
tag = m.group(1)
self.tags.append(tag)
str = m.group(2)
return None
def AddCc(self, cc_list):
"""Add a list of people to Cc when we send this patch.
Args:
cc_list: List of aliases or email addresses
"""
self.cc_list += cc_list
def CheckDuplicateSignoff(self, signoff):
"""Check a list of signoffs we have send for this patch
Args:
signoff: Signoff line
Returns:
True if this signoff is new, False if we have already seen it.
"""
if signoff in self.signoff_set:
return False
self.signoff_set.add(signoff)
return True
def AddRtag(self, rtag_type, who):
"""Add a response tag to a commit
Args:
key: rtag type (e.g. 'Reviewed-by')
who: Person who gave that rtag, e.g. 'Fred Bloggs <fred@bloggs.org>'
"""
self.rtags[rtag_type].add(who)