This commit is preparation work for the transition to Python 3.x,
where the output obtained by running Git commands will become
bytes as opposed to a string. In the vast majority of cases,
we'll want to decode that output into a string. Ideally, we would
want to do this in a way that is both compatible with Python 2.x
and Python 3.x, but we have found that this requires a lot of
work with many changes spread all over the code. So, instead,
what this commit does is introduce the concept of decoding
the output, but with the decoding only occurring when running
under Python 3.x.
That way, we can make progress towards Python 3.x while preserving
the behavior under Python 2.x intact.
Change-Id: I189577798ee96cba1fa55c7356babf102575642f
TN: U530-006
This is another Python 3.x preparation patch, which fixes a situation
where we change a dictionary size while iterating over it, something
that became apparent while exercizing the hooks with Python 3.x.
This commit avoids this by rewriting this part of the function
in a way that aboves the dictionary iteration entirely.
TN: U530-006
Change-Id: Ia22b28919ac2dabc3e22ed1b3652e14d799e566b
I noticed while working on the transition to Python 3.x that
this argument is not actually used, so this commit removes it.
It makes the API for this function simpler and also helps avoid
some pitfalls (as shown by one of the limitations we documented
that this commit removes).
TN: U530-006
Change-Id: I5ced7c6a979c5381d35498b06f1af8c569a3f9ed
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
The use of the "git log" command allows us to avoid having to
post-process the command's output in order to extra the subject.
Found while working on U530-006 (transition to Python 3).
Change-Id: I96e9545deece7a2094f9637b75d5e7fb6f334d9a
dict.iteritems is Python2-only, so this commit replaces it by
the equivalent call to the "items" method instead.
Change-Id: Ifd2a4e0ce2f00d7d69af9d88a9c959662801a972
This type will disappear when using a Python 3.x interpreter.
In the meantime, while this code is still run using a Python 2.7
interpreter, it's not a loss in practice to use "str" instead
because we do not use this code in a context where we pass
a unicode string as the _outfile parameter.
Change-Id: Ib56c1521324ee8a8b8b89a7d3b97f43328c313bb
This is preparatory work for being to pass a certain amount of data
to user-defined hooks. The intent of this change is to limit the number
of times we compute that information to at most once.
Generally speaking, the main part of this change consists in adding
the following new methods to class CommitInfo:
- raw_revlog;
- raw_revlog_lines; and
The rest of this change is mostly adjustments to the code that needs
to access commits' rev logs to get them from a shared CommitInfo object
rather than from a play revision (SHA1).
Additionally, the function is_revert_commit in git.py, which took
a commit revision as a paramenter and needed a call to "git log"
to get the commit's body, has been replaced by a new method in
class CommitInfo. An alternative approach might have been to
keep the function, and change its parameter to be a CommitInfo object.
But it seemed more natural to make this a method of the CommitInfo
class instead, so this is what this change does.
Change-Id: Ia4bf23f24226d1e9eddafc61afd37db37f0f5287
TN: T209-005
This change modifies the git_run function, which is a generic
function at the center of all calls to Git, to stop stripping
the start of the output of whitespaces and newlines.
While running the testsuite without any stripping at all clearly
reveals why stripping of the end of the output is necessary (see
added comment for that), stripping of the start of the output
introduces some limitations. For instance, we might want to verify
that commit subjects don't start with spaces.
Since there is no reason that we know of that we would want to strip
the start of the output of Git commands, this change adjusts git_run
accordingly.
TN: T209-005
Change-Id: Ic48a10b4f6115eecc7dbe1c7bb2300ba6070d867
This patch introduces a git-hooks config which allows users to tell
the git-hooks to ignore a set of references (as if these references
actually did not exist). By default, the list of ignored references
has one entry, which corresponds to some references that gerrit
creates internally (refs/changes/.*).
For P812-021.
This can be useful in any situation, but the use-case that prompted
this enhancement came from the fact that git calls the hooks with
the GIT_DIR environment variable set. If we want to manipulate another
git repository, this GIT_DIR gets in the way, as it points right back
to the original repository. By being able to pass the environment,
we can pass a copy which does not include GIT_DIR.
For P531-036.
The CommitInfo currently has a base_rev attribute which currently
was only half-handled. Part of it was set up by commit_info_list,
except that it wasn't really done properly, so the updates class
was re-doing it afterwards. And then we had this slightly confusing
situation I wasn't sure whether a None base_rev meant no base
(root commit), or un-calculated yet.
This patch clarifies this by getting rid of the "base_rev" attribute,
replacing it by a "parent_revs" attribute, which is either None if
un-calculated yet, or else a list, which would be empty if the commit
has no parent (root commit).
This allows us to simplify a couple of areas, but otherwise, this
is just fallout from those changes.
This should also help us prepare for having easy access to the list
of changes a commit introduces, which is going to be necessary to
handle the FSF's binutils-gdb.git repository.
For NC07-001.
With git version 1.8.3.2, "git cat-file -p" no longer pretty-prints
the date, printing a timestamp instead. This patch adjust the code
that gets tagger name/email and date to work around this new behavior,
in a way that should with both old and new versions of git.
Add a gigantic comment explaining how we do it and why.
... instead of getting the entire list of commits, only to keep
the first one. This dramatically improves performance in repositories
such as GDB where branches contain a very large number of commits.
Combined with the identical type of fix done in commit_oneline,
the time required for a "git push" in the GDB repository went down
from 40 seconds down to 3.5 seconds!
... instead of getting the entire list of commits only to keep the
first one. This dramatically improves performance during the
post-receive phase, when the repository has branches with a very
large number of commits (such as GDB, for instance).
... since we are only ever going to use the first one anyway.
This change dramatically improves the performance for projects
such as GCC or GDB, which already have a very long history of
commits. With the GDB project, it was measured to reduce the
duration of a push by 57%!
