summaryrefslogtreecommitdiff
path: root/templates/hooks--update
AgeCommit message (Collapse)AuthorFilesLines
2008-01-17Officially deprecate repo-config.Libravatar Junio C Hamano1-3/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-08hooks--update: decline deleting tags or branches by default, add config optionsLibravatar Gerrit Pape1-2/+31
Decline deleting tags or branches through git push <remote> :<ref> by default, support config options hooks.allowdeletetag, hooks.allowdeletebranch to override this per repository. Before this patch the update hook interpreted deleting a tag, no matter if annotated or not, through git push <remote> :<tag> as unannotated tag, and declined it by default, but with an unappropriate error message: $ git push origin :atag deleting 'refs/tags/atag' *** The un-annotated tag, atag, is not allowed in this repository *** Use 'git tag [ -a | -s ]' for tags you want to propagate. ng refs/tags/atag hook declined error: hooks/update exited with error code 1 error: hook declined to update refs/tags/atag error: failed to push to 'monolith:/git/qm/test-repo' Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-08hooks--update: fix test for properly set up project description fileLibravatar Gerrit Pape1-2/+2
The update hook template intends to abort if the project description file hasn't been adjusted or is empty. This patch fixes the check for 'being adjusted'. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13hooks--update: Explicitly check for all zeros for a deleted ref.Libravatar Alexandre Julliard1-1/+1
The previous check caused the hook to reject as unannotated any tag whose SHA1 starts with a zero. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-16Have sample update hook not refuse deleting a branch through push.Libravatar Gerrit Pape1-1/+6
source ref might be 0000...0000 to delete a branch through git-push, 'git <remote> push :<branch>'. The update hook should not decline this. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16variable $projectdesc needs to be set before checking against unchanged default.Libravatar Gerrit Pape1-0/+1
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-24update-hook: remove e-mail sending hook.Libravatar Andy Parkins1-222/+3
The update hook's only job is to decide is a particular update is allowed or not. It was not the right place to send out update notification e-mails from to begin with, as the final stage of updating refs can fail after this hook runs. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-22update-hook: abort early if the project description is unsetLibravatar Andy Parkins1-0/+6
It was annoying to always have the first email from a project be from the "Unnamed repository; edit this file to name it for gitweb project"; just because it's so easy to forget to set it. This patch checks to see if the description file is still default (or empty) and aborts if so - allowing you to fix the problem before sending out silly looking emails to every developer. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-14update-hook: fix incorrect use of git-describe and sed for finding previous tagLibravatar Andy Parkins1-1/+1
Previously git-describe would output lines of the form v1.1.1-gf509d56 The update hook found the dash and stripped it off using sed 's/-g.*//' The remainder was then used as the previous tag name. However, git-describe has changed format. The output is now of the form v1.1.1-23-gf509d56 The above sed fragment doesn't strip the middle "-23", and so the previous tag name used would be "v1.1.1-23". This is incorrect. Since the hook script was written, git-describe now gained support for "--abbrev=0", which it uses as a special flag to tell it not to output anything other than the nearest tag name. This patch fixes the problem, and prevents any future recurrence by using this new flag rather than sed to find the previous tag. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-02Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Fix quoting in update hook template
2007-03-02Fix quoting in update hook templateLibravatar Gerrit Pape1-1/+1
By default allowunannotated is unset in the repo config, hence $allowunannotated is empty, and must be quoted to not break the syntax. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-02Sample update hook: typofix and modernization to use "git log"Libravatar Andy Parkins1-5/+4
Instead of using antiquated "git-rev-parse | git-rev-list" pipeline, it is easier to use "git-rev-list" or "git-log" these days, as Linus points out. While we are at it, fix the typo on variable name $newref that should be $newrev. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14The "table-of-contents" in the update hook script should match the bodyLibravatar Andy Parkins1-2/+2
44478d99ee0 introduced a filter using "git-rev-parse --not --all" to the log display to prevent the display of revisions already in the repository. However, the table of contents generation didn't get that same update. This patch fixes that. The table of contents before the log and the log now both display the same list of revisions. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13Only show log entries for new revisions in hooks--updateLibravatar Andy Parkins1-1/+2
If you were issuing emails for two branches, and one merged the other, you would get the same log messages appearing in two separate emails. e.g. A working repository, where the last push to central was done at the revision marked "B", after which two branches were developed further. * -- B -- 1 -- 1 -- M (branch1) \ / 2 -- 2 -- 2 (branch2) Now imagine that branch2 is pushed to the email-generating repository; an email containing all the "2" revisions would be sent. Now, let's say branch1 is pushed, the old update hook would run git-rev-list $newrev ^$baserev Where $newrev would be "M" and $baserev would be "B". This list includes all the "2" revisions as well as all the "1" revisions. This patch addresses this problem by using git-rev-parse --not --all | git-rev-list --stdin $newrev ^$baserev To inhibit the display of all revisions that are already in the repository. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13Fix potential command line overflow in hooks--updateLibravatar Andy Parkins1-1/+1
In a repository with a large number of refs, the following command line could easily overflow the command line size limitations git-rev-list $newref $(git-rev-parse --not --all) Fortunately, git-rev-list already has the means to cope with this situation with the --stdin switch git-rev-parse --not --all | git-rev-list --stdin $newref Which is exactly what this patch does. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Heavily expanded update hook to send more useful emails than the old hookLibravatar Andy Parkins1-72/+268
I know it's only an example, but having this might save someone else the trouble of writing an enhanced version for themselves. It basically does the same job as the old update hook, but with these differences: * The recipients list is read from the repository config file from hooks.mailinglist * Updating unannotated tags can be allowed by setting hooks.allowunannotated * Announcement emails (via annotated tag creation) can be sent to a different mailing list by setting hooks.announcelist * Output email is more verbose and generates specific content depending on whether the ref is a tag, an annotated tag, a branch, or a tracking branch * The email is easier to filter; the subject line is prefixed with [SCM] and a project description pulled from the "description" file * It catches (and displays differently) branch updates that are performed with a --force Obviously, it's nothing that clever - it's the update hook I use on my repositories but I've tried to keep it general, and tried to make the output always relevant to the type of update. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28UNIX reference time of 1970-01-01 00:00 is UTC timezone, not local time zoneLibravatar Andy Parkins1-1/+1
I got bitten because in the UK (where one would expect 1970-01-01 00:00 to be UTC 0) some politicians decided to mess around with daylight savings time from 1968 to 1971; it was permanently BST (+0100). That means that on my computer the following is true: $ date --date="1970-01-01 00:00" +"%F %T %z (%Z)" 1970-01-01 00:00:00 +0100 (BST) This of course means that the --date argument to date is specified in local time, not UTC. So when the hooks--update script does this: date=$(date --date="1970-01-01 00:00:00 $ts seconds") It's actually saying (in my timezone) "1970-01-01 01:00:00 UTC" + $ts. Clearly this is wrong. The UNIX epoch started at midnight UTC not 1am UTC. This leads to the tagged time in hooks--update being shown as one hour earlier than the true tagged time (in my timezone). The problem would be worse for other timezones. For a +1300 timezone on 1970-01-01, the tagged time would be 13 hours earlier. Oops. The solution is to force the reference time to UTC, which is what this patch does. In my timezone: $ date --date="1970-01-01 00:00 +0000" +"%F %T %z (%Z)" 1970-01-01 01:00:00 +0100 (BST) Much better. Signed-off-by: Andy Parkins <andyparkins@gmail.com>
2006-12-28update hook: redirect _both_ diagnostic lines to stderr upon tag failureLibravatar Jim Meyering1-1/+1
Otherwise, sending the diagnostic to stdout would provoke a protocol failure. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-08templates/hooks--update: replace diffstat calls with git diff --statLibravatar Eric Wong1-2/+2
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-24sample update-hook: sanely handle a new branch head.Libravatar Junio C Hamano1-1/+1
Instead of showing all the history since the beginning of time leading to the the branch head, show only the changes this new branch brings to the world. This originally came from Linus and tested by Andreas Ericsson. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-24update-hook: Major overhaul (handling tags, mainly).Libravatar Andreas Ericsson1-6/+65
This is the update hook we use in all our git-repos. It has some improvements over the original version, namely: * Don't send every commit since dawn of time when adding a new tag. * When updating an annotated tag, just send the diffs since the last tag. * Add diffstat output for 'normal' commits (top) and annotated tags (bottom). * Block un-annotated tags in shared repos. I'm a bit uncertain about that last one, but it demonstrates how to disallow updates of a ref which we use, so I kept it. Note that git-describe is needed for the "changes since last annotated tag" thing to work. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21Fix hooks/update template.Libravatar Junio C Hamano1-4/+3
Make the example address RFC2606 (aka BCP0032) compliant. Also fix a couple of shell script errors. Noted and fixed by Matthew Wilcox and Andreas Ericsson. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-02scripts: equality test '==' is not portable.Libravatar Junio C Hamano1-2/+6
On NetBSD 3 we trigger an error: [: ==: unexpected operator Double-equal is accepted by bash built-in '[' and bash(1) suggests using '=' for strict POSIX compliance (test(1) from coreutils does not mention '=='). Eradicate their uses everywhere. [jc: Somebody with a pseudonym kindly sent a message to let me know about the problem privately; I do not have access to a NetBSD box.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-15[PATCH] Fixed/Extended example for update hookLibravatar Josef Weidendorfer1-3/+9
Add sample code to distinguish --force rebased head and simple fast-forward. At the same time fixes a real bug; the "new ref" path was using a wrong parameter. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-03Install sample hooksLibravatar Junio C Hamano1-0/+21
A template mechanism to populate newly initialized repository with default set of files is introduced. Use it to ship example hooks that can be used for update and post update checks, as Josef Weidendorfer suggests. Signed-off-by: Junio C Hamano <junkio@cox.net>