prep_for_email neither is passed a fourth argument nor uses it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
first place. According to the Debian policy they should be located in
/usr/share/git-core/, so let's put them there.
Thanks to Bill Allombert for reporting this through
http://bugs.debian.org/640949
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes it easy to customize the git diff-tree options, for example
to include -p to include inline diffs.
It defaults to the current options "--stat --summary --find-copies-harder"
and thus is backward-compatible.
Signed-off-by: Jon Jensen <jon@endpoint.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function was returning 0 for failure and 1 for success which was
breaking the logic in the main loop. It now also returns in all
cases, rather than exiting.
Signed-off-by: Alan Raison <alan@theraisons.me.uk>
Acked-by: Kevin P. Fleming <kpfleming@digium.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Changes the logic in the script to determine whether an email message
will be sent before invoking the send_mail() function; otherwise, if
the logic determines that a message will not be sent, send_mail() will
cause an empty email to be sent. In addition, ensures that if multiple
refs are updated and a message cannot be sent for one of them,
the others are still processed normally.
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous form produced subjects like
[SCM] project.git branch, foo, updated. ...
The new one will produce the lighter
[SCM] project.git branch foo updated. ...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have become used to the features of svnmailer when used with Subversion,
and one of those useful features is that it can limit the maximum length
(in lines) of a commit email message. This is terribly useful since once the
goes beyond a reasonable number of lines, nobody is going to read the remainder,
and if they really want the entire contents of the commits, they can use
git itself to get them using the revision IDs present in the message already.
Change the post-receive-email script to respond to an 'emailmaxlines' config key
which, if specified, will limit the number of lines generated (including
headers); any lines beyond the limit are suppressed, and a final line is added
indicating the number that were suppressed.
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the default hooks/post-receive file, the hook is called
with three arguments on stdin:
<oldrev> <newrev> <refname>
In command-line mode, the arguments come in a different order, because
the email hook instead calls:
generate_email $2 $3 $1
Add a comment to explain why, based on comments from the mailing list
and the commit message to v1.5.1~9. Thanks to Andy for the
explanation.
Requested-by: martin f. krafft <madduck@debian.org>
Cc: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a comment showing how to include a web link (i.e. gitweb/cgit)
and a patch in the email that is sent for each pushed commit.
The quoting was tricky enough that it's worth documenting. To add
two blank lines (i.e. put \n\n in the printf), you would need to
say \\\\n\\\\n, and in the end, the pair of "echo" statements seemed
better. This is used in glibc.git repository:
http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=summary
push-triggered messages have been sent to this list since May 21:
http://sourceware.org/ml/glibc-cvs/2009-q2/
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the show_new_revisions function, the original code:
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
isn't quite right since one can create a new branch and push it
without any new commits. In that case, two refs will have the same
sha1 but both would get filtered by the 'grep'. In the end, we'll
show ALL the history which is not what we want. Instead, we should
list the branches by name and remove the branch being updated and THEN
pass that list through rev-parse.
Revised as suggested by Jakub Narebski and Junio C Hamano to use
git-for-each-ref instead of git-branch. (Thanks!)
Signed-off-by: Pat Notz <pknotz@sandia.gov>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add configuration option hooks.showrev, letting the user override how
revisions will be shown in the commit email.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The display of a revision in an email-appropriate format is done in
two places with similar code. In preparation for making that display
more complex, move it into a separate function that handles both cases.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the hook gets invoked with identical old and new ids there
is no change taking place. We probably should not have been
called, but instead of failing silently allow the no-op.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a user or group ACL file does not exist in the current tip
revision of the acl repository we will get an error from cat-file
when we ask for that blob as it cannot be resolved. A quick look
at the history by rev-list can tell us if there is a path there
or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Listing all files in a branch during branch creation is silly;
the user's file-level ACLs probably don't mean anything at this
point. We now treat the base case of 0{40} as an empty diff,
as this happens only when the user is creating the branch and
there are file level ACLs that diff against the old value of
the branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
post-receive-email: fix accidental removal of a trailing space in signature line
Escape project names before creating pathinfo URLs
Escape project name in regexp
bash: Add completion for git diff --base --ours --theirs
diff-options.txt: document the new "--dirstat" option
post-receive-email adds a signature to the end of emails in
generate_email_footer(). The signature was separated from the main email
body using the standard string "-- ". (see RFC 3676)
a6080a0 (War on whitespace, 2007-06-07) removed the trailing whitespace
from "-- ", leaving it as "--", which is not a correct signature
separator.
This patch restores the missing space, but does it in a way that will
not set off the trailing whitespace alarms.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It disables git-gc --auto when you are running Linux and you are
not on AC.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following patch will introduce a new configuration variable,
"format.pretty", from then on the pretty format without specifying
"--pretty" might not be the default "--pretty=medium", it depends on
the user's config. So all kinds of Shell/Perl/Emacs scripts that needs
the default medium pretty format must specify it explicitly.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Switch all git command calls to use the git (space) command format, and
remove the use of git-repo-config in place of git config.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Email subjects are prefixed with "[SCM] " by default, make this optionally
configurable through the hooks.emailprefix config option.
Suggested by martin f krafft through
http://bugs.debian.org/428418
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Yet more 1.5.3.5 fixes mentioned in release notes
cvsserver: Use exit 1 instead of die when req_Root fails.
git-blame shouldn't crash if run in an unmerged tree
git-config: print error message if the config file cannot be read
fixing output of non-fast-forward output of post-receive-email
post-receive-email has one place where the variable fast_forward is not
spelled correctly. At the same place the logic was reversed. The
combination of both bugs made the script work correctly for fast-forward
commits but not for non-fast-forward ones. This change fixes this to
be correct in both cases.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Have the error message for missing recipients actually report the
missing config variable and not a fictional one.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Whip post 1.5.3.3 maintenance series into shape.
git stash: document apply's --index switch
post-receive-hook: Remove the From field from the generated email header so that the pusher's name is used
Using the name of the committer of the revision at the tip of the
updated ref is not sensible. That information is available in the email
itself should it be wanted, and by supplying a "From", we were
effectively hiding the person who performed the push - which is useful
information in itself.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Do not over-quote the -f envelopesender value.
unexpected Make output (e.g. from --debug) causes build failure
Fixed minor typo in t/t9001-send-email.sh test command line.
Without this, the value passed to sendmail would have an extra set of
single quotes. At least exim's sendmail emulation would object to that:
exim: bad -f address "'list-addr@example.org'": malformed address: ' \
may not follow 'list-addr@example.org
error: hooks/post-receive exited with error code 1
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usage info is emebed in the script, but the gist of it is to run the script
from a pre-commit hook to save permissions/ownership data to a file and check
that file into the repository. Then, a post_merge hook reads the file and
updates working tree permissions/ownership. All updates are transparent to
the user (although there is a --verbose option). Merge conflicts are handled
in the "read" phase (in pre-commit), and the script aborts the commit and
tells you how to fix things in the case of a merge conflict in the metadata
file. This same idea could be extended to handle file ACLs or other file
metadata if desired.
Signed-off-by: Josh England <jjengla@sandia.gov>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have to load a tree difference for the purpose of testing
file patterns. But if our branch is being created and there is no
specific base to difference against in the rule our base will be
'0'x40. This is (usually) not a valid tree-ish object in a Git
repository, so there's nothing to difference against.
Instead of creating the empty tree and running git-diff against
that we just take the output of `ls-tree -r --name-only` and mark
every returned pathname as an add.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some applications of the update hook a user may be allowed to
modify a branch, but only if the file level difference is also an
allowed change. This is the commonly requested feature of allowing
users to modify only certain files.
A new repository.*.allow syntax permits granting the three basic
file level operations:
A: file is added relative to the other tree
M: file exists in both trees, but its SHA-1 or mode differs
D: file is removed relative to the other tree
on a per-branch and path-name basis. The user must also have a
branch level allow line already granting them access to create,
rewind or update (CRU) that branch before the hook will consult
any file level rules.
In order for a branch change to succeed _all_ files that differ
relative to some base (by default the old value of this branch,
but it can also be any valid tree-ish) must be allowed by file
level allow rules. A push is rejected if any diff exists that
is not covered by at least one allow rule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some applications of this paranoid update hook the set of ACL
rules that need to be applied to a user can be large, and the
number of users that those rules must also be applied to can be
more than a handful of individuals. Rather than repeating the same
rules multiple times (once for each user) we now allow users to be
members of groups, where the group supplies the list of ACL rules.
For various reasons we don't depend on the underlying OS groups
and instead perform our own group handling.
Users can be made a member of one or more groups by setting the
user.memberOf property within the "users/$who.acl" file:
[user]
memberOf = developer
memberOf = administrator
This will cause the hook to also parse the "groups/$groupname.acl"
file for each value of user.memberOf, and merge any allow rules
that match the current repository with the user's own private rules
(if they had any).
Since some rules are basically the same but may have a component
differ based on the individual user, any user.* key may be inserted
into a rule using the "${user.foo}" syntax. The allow rule does
not match if the user does not define one (and exactly one) value
for the key "foo".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The sed command that extracted the first line of the project description
didn't include the -n switch and hence the project name was being
printed twice. This was ruining the email header generation because it
was assumed that the description was only one line and was included in
the subject. This turned the subject into a two line item and
prematurely finished the header.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes a non-fast-forward update doesn't add new commits, it merely
removes old commits. This patch adds support for detecting that and
outputting a more correct message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm using a variant of this update hook in a corporate environment
where we perform some validations of the commits and tags that
are being pushed. The model is a "central repository" type setup,
where users are given access to push to specific branches within
the shared central repository. In this particular installation we
run a specially patched git-receive-pack in setuid mode via SSH,
allowing all writes into the repository as the repository owner,
but only if this hook blesses it.
One of the major checks we perform with this hook is that the
'committer' line of a commit, or the 'tagger' line of a new annotated
tag actually correlates to the UNIX user who is performing the push.
Users can falsify these lines on their local repositories, but
the central repository that management trusts will reject all such
forgery attempts. Of course 'author' lines are still allowed to
be any value, as sometimes changes do come from other individuals.
Another nice feature of this hook is the access control lists for
all repositories on the system can also be stored and tracked in
a supporting Git repository, which can also be access controlled
by itself. This allows full auditing of who-had-what-when-and-why,
thanks to git-blame's data mining capabilities.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
