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%!
... Enforcing the policy that users should push their "regular"
commits first (update a branch, for instance), and then push
the notes commits.
Fixes LC24-002.
I would like to keep the git.py module as a low-level layer to access
git. The higher-level, more git-hooks-oriented functionality, should
(and is) elsewhere.
The patch adjusts the one caller to rev_list_commits, which really
doesn't need such an elaborate function to get what it needs.
It also renames "load_commit" into commit_rev, as it now returns
just the commit revision, rather than a GitCommit object.
The "commit_oneline" is adjusted accordingly also.
And finally, this introduces a function called "commit_subject".
I think that the old algorithm was completely (logically) flawed.
The new approach returns a list of commits that provides:
- the expansion of old_rev..new_rev
- which commits in this expanded let are new for the repo
(and thus requires a commit email).
This will help generate a more descriptive cover email.
This attribute is used to store the value of all references
before an update is applied.
This was computed on-demand by expand_new_commit_to_list, but we want
to make this a parameter of this function, in order to allow us to
call this function from any hook. In particular, in the post-receive
hook, all reference values have already been updated, so the only
way to get the value of a reference prior to the update is by reverse-
applying the ref updates passed by argument to the post-receive hook.
The ultimate goal of this patch is to re-use expand_new_commit_to_list
during the phase where we send emails for each new commit.
For our purposes, we would always want _quiet to be True, whereas
the default was False, leading to a lot of situations where we forgot
to set it. So we delete the option. To access the command's output
in case of command failure, now use the CalledProcessError exception's
output method.
One of the changes also introduced by this patch is the fact that
stderr is now redirected to stdout.
This will avoid seeing some inexplicable spaces in the output
printed by git push commands. These spaces were in fact coming
from the "print" statements that we just got rid of - triggered
by the fact that some calls to git_run were missing the _quiet
option.
