1 The following metrics will be used to determine if something is a fix:
2 * If a commit is made on a specific branch after a specific commit.
4 For example, all commits that are made in a maintenance
5 branch are guaranteed to be fixes. The problem here is
6 that usually a maintenance branch is 'branched off' the
7 mainstream branch at the point of a release, as such
8 there has to be a lower limit (say, the 'creation point'
9 of the branch) from where on commits are seen as 'part of
10 the maintenance branch'. This means that when specifying
11 which branches are matches not only the branch name
12 should be specified, but also the starting commit.
14 * If the commit message matches a certain regexp.
16 For example, if the commit message contains the line:
17 'this fixes', it is a fix. The regexp can be as simple
18 as matching 'fix ' or 'fixes ', there will probably
19 be little need for advanced regexp machinery.
21 * If the diff contains a specific change, matching a certain regexp.
23 For example, in a test suite there might be an indicator
24 for known breakages, when this indicator is changed from
25 'known breakage' to 'should pass' the commit fixed the
28 * If the commit reverts another commit.
30 Whenever a commit reverts another one, the reverted
31 commit was a mistake, and as such the reverting commit is
32 a fix. By first checking which commits touch the same
33 files the commits that have to be checked can be reduced
36 * If a commit touches nearly all the same lines as another commit
38 Commits that are not actual reverts, but that do touch
39 the same files are very likely to be fixes. But, if the
40 commit is from the same author, made shortly after the
41 first commit, it is likely to be from the same 'patch
42 series' and as such should not be treated as a fix.