summaryrefslogtreecommitdiff
path: root/contrib/hooks
AgeCommit message (Collapse)AuthorFilesLines
2011-02-07post-receive-email: suppress error if description file missingLibravatar Sitaram Chamarty1-1/+1
Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09contrib/hooks/post-receive-email: fix return values from prep_for_emailLibravatar Alan Raison1-4/+4
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>
2010-11-24Merge branch 'kf/post-receive-sample-hook' into maintLibravatar Junio C Hamano1-16/+31
* kf/post-receive-sample-hook: post-receive-email: ensure sent messages are not empty
2010-09-10post-receive-email: ensure sent messages are not emptyLibravatar Kevin P. Fleming1-16/+31
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>
2010-08-18Merge branch 'kf/post-receive-sample-hook'Libravatar Junio C Hamano1-2/+32
* kf/post-receive-sample-hook: post-receive-email: optional message line count limit
2010-08-11post-receive-email: remove spurious commas in email subjectLibravatar Matthieu Moy1-1/+1
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>
2010-07-16post-receive-email: optional message line count limitLibravatar Kevin P. Fleming1-2/+32
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>
2010-05-19post-receive-email: document command-line modeLibravatar Jonathan Nieder1-0/+7
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>
2009-10-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-3/+3
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23post-receive-email: hooks.showrev: show how to include both web link and patchLibravatar Jim Meyering1-0/+4
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>
2009-02-11Fix contrib/hooks/post-receive-email for new duplicate branchLibravatar Pat Notz1-1/+3
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>
2008-11-04contrib/hooks/post-receive-email: Make revision display configurableLibravatar Pete Harlan1-1/+17
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>
2008-11-04contrib/hooks/post-receive-email: Put rev display in separate functionLibravatar Pete Harlan1-9/+32
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>
2008-10-14Add Linux PPC support to the pre-auto-gc example hookLibravatar Miklos Vajna1-0/+3
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-30Add OS X support to the pre-auto-gc example hookLibravatar Jonathan del Strother1-3/+7
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>
2008-09-22Use dashless git commands in setgitperms.perlLibravatar Todd Zullinger1-2/+2
Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Ignore no-op changes in paranoid update hookLibravatar Shawn O. Pearce1-0/+1
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>
2008-05-25Don't load missing ACL files in paranoid update hookLibravatar Shawn O. Pearce1-0/+1
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>
2008-05-25Don't diff empty tree on branch creation in paranoid update hookLibravatar Shawn O. Pearce1-8/+6
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>
2008-04-22Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* 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
2008-04-21post-receive-email: fix accidental removal of a trailing space in signature lineLibravatar Andy Parkins1-1/+2
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>
2008-04-09contrib/hooks: add an example pre-auto-gc hookLibravatar Miklos Vajna1-0/+36
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>
2008-03-05specify explicit "--pretty=medium" with `git log/show/whatchanged`Libravatar Denis Cheng1-1/+1
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>
2008-01-13Remove usage of git- (dash) commands from email hookLibravatar Dan McGee1-17/+17
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>
2007-11-08contrib/hooks/post-receive-email: remove cruft, $committer is not usedLibravatar Gerrit Pape1-4/+0
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-07contrib/hooks/post-receive-email: make subject prefix configurableLibravatar Gerrit Pape1-3/+5
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>
2007-11-07contrib/hooks/post-receive-email: reformat to wrap comments at 76 charsLibravatar Gerrit Pape1-92/+107
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-07contrib/hooks/post-receive-email: fix typoLibravatar Gerrit Pape1-1/+1
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-18Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* 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
2007-10-18fixing output of non-fast-forward output of post-receive-emailLibravatar Robert Schiele1-1/+1
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>
2007-10-15Minor usage update in setgitperms.perlLibravatar Josh England1-3/+4
Signed-off-by: Josh England <jjengla@sandia.gov> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15fix contrib/hooks/post-receive-email hooks.recipients error messageLibravatar Jeff Muizelaar1-1/+9
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>
2007-10-01Merge branch 'maint'Libravatar Junio C Hamano1-1/+0
* 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
2007-10-01post-receive-hook: Remove the From field from the generated email header so ↵Libravatar Andy Parkins1-1/+0
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>
2007-09-25Merge branch 'maint'Libravatar Junio C Hamano1-6/+10
* 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.
2007-09-25Do not over-quote the -f envelopesender value.Libravatar Jim Meyering1-6/+10
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>
2007-09-18Added example hook script to save/restore permissions/ownership.Libravatar Josh England1-0/+213
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>
2007-08-10Use the empty tree for base diff in paranoid-update on new branchesLibravatar Shawn O. Pearce1-10/+21
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>
2007-08-10Teach the update-paranoid to look at file differencesLibravatar Shawn O. Pearce1-7/+105
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>
2007-08-10Teach update-paranoid how to store ACLs organized by groupsLibravatar Shawn O. Pearce1-16/+44
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>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+1
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>
2007-04-26post-receive-email example hook: sed command for getting description was wrongLibravatar Andy Parkins1-1/+1
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>
2007-04-26post-receive-email example hook: detect rewind-only updates and output ↵Libravatar Andy Parkins1-23/+54
sensible message 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>
2007-04-26post-receive-email example hook: fastforward should have been fast_forwardLibravatar Andy Parkins1-1/+1
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-19Contribute a fairly paranoid update hookLibravatar Shawn O. Pearce1-0/+284
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>
2007-04-04rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.Libravatar Gerrit Pape1-0/+0
$ git grep post-receieve-email $ git grep post-receive-email templates/hooks--post-receive:#. /usr/share/doc/git-core/contrib/hooks/post-receive-email $ Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-31Reimplement emailing part of hooks--update in contrib/hooks/post-receive-emailLibravatar Andy Parkins1-0/+588
The update hook is no longer the correct place to generate emails; there is now the hooks/post-receive script which is run automatically after a ref has been updated. This patch is to make use of that new location, and to address some faults in the old update hook. The primary problem in the conversion was that in the update hook, the ref has not actually been changed, but is about to be. In the post-receive hook the ref has already been updated. That meant that where we previously had lines like: git rev-list --not --all would now give the wrong list because "--all" in the post-receive hook includes the ref that we are making the email for. This made it more difficult to show only the new revisions added by this update. The solution is not pretty; however it does work and doesn't need any changes to git-rev-list itself. It also fixes (more accurately: reduces the likelihood of) a nasty race when another update occurs while this script is running. The solution, in short, looks like this (see the source code for a longer explanation) git rev-parse --not --all | grep -v $(git rev-parse $refname) | git rev-list --pretty --stdin $oldrev..$newrev This uses git-rev-parse followed by grep to filter out the revision of the ref in question before it gets to rev-list and inhibits the output of itself. By using $(git rev-parse $revname) rather than $newrev as the filter, it also takes care of the situation where another update to the same ref has been made since $refname was $newrev. The second problem that is addressed is that of tags inhibiting the correct output of an update email. Consider this, with somebranch and sometag pointing at the same revision: git push origin somebranch git push origin sometag That would work fine; the push of the branch would generate an email containing all the new commits introduced by the update, then the push of the tag would generate the shortlog formatted tag email. Now consider: git push origin sometag git push origin somebranch When some branch comes to run its "--not --all" line, it will find sometag, and filter those commits from the email - leaving nothing. That meant that those commits would not show (in full) on any email. The fix is to not use "--all", and instead use "--branches" in the git-rev-parse command. Other changes * Lose the monstrous one-giant-script layout and put things in easy to digest functions. This makes it much easier to find the place you need to change if you wanted to customise the output. I've also tried to write more verbose comments for the same reason. The hook script is big, mainly because of all the different cases that it has to handle, so being easy to navigate is important. * All uses of "git-command" changed to "git command", to cope better if a user decided not to install all the hard links to git; * Cleaned up some of the English in the email * The fact that the receive hook makes the ref available also allows me to use Shawn Pearce's fantastic suggestion that an annotated tag can be parsed with git-for-each-ref. This removes the potentially non-portable use of "<<<" heredocs and the nasty messing around with "date" to convert numbers of seconds UTC to a real date * Deletions are now caught and notified (briefly) * To help with debugging, I've retained the command line mode from the update hook; but made it so that the output is not emailed, it's just printed to the screen. This could then be redirected if the user wanted * Removed the "Hello" from the beginning of the email - it's just noise, and no one seriously has their day made happier by "friendly" programs * The fact that it doesn't rely on repository state as an indicator any more means that it's far more stable in its output; hopefully the same arguments will always generate the same email - even if the repository changes in the future. This means you can easily recreate an email should you want to. * Included Jim Meyering's envelope sender option for the sendmail call * The hook is now so big that it was inappropriate to copy it to every repository by keeping it in the templates directory. Instead, I've put a comment saying to look in contrib/hooks, and given an example of calling the script from that template hook. The advantage of calling the script residing at some fixed location is that if a future package of git included a bug fixed version of the script, that would be picked up automatically, and the user would not have to notice and manually copy the new hook to every repository that uses it. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>