kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Jonathan Nieder	cc24a1d809	post-receive-email: document command-line mode 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>	15 years ago
Felipe Contreras	a75d7b5409	Use 'fast-forward' all over the place It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jim Meyering	5ffd3113d4	post-receive-email: hooks.showrev: show how to include both web link and patch 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>	16 years ago
Pat Notz	e5f5050ed1	Fix contrib/hooks/post-receive-email for new duplicate branch 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>	16 years ago
Pete Harlan	b0a7d11173	contrib/hooks/post-receive-email: Make revision display configurable 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>	16 years ago
Pete Harlan	4471649f44	contrib/hooks/post-receive-email: Put rev display in separate function 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>	16 years ago
Andy Parkins	71bd81ade2	post-receive-email: fix accidental removal of a trailing space in signature line 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>	17 years ago
Denis Cheng	9225d7be0a	specify explicit "--pretty=medium" with `git log/show/whatchanged` 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>	17 years ago
Dan McGee	22fa97d4e0	Remove usage of git- (dash) commands from email hook 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>	17 years ago
Gerrit Pape	5c355059c3	contrib/hooks/post-receive-email: remove cruft, $committer is not used Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Gerrit Pape	e7509ee388	contrib/hooks/post-receive-email: make subject prefix configurable 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>	17 years ago
Gerrit Pape	15a2f53011	contrib/hooks/post-receive-email: reformat to wrap comments at 76 chars Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Gerrit Pape	b5786c8283	contrib/hooks/post-receive-email: fix typo Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Robert Schiele	a2d6b872db	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>	17 years ago
Jeff Muizelaar	fdfeb87c14	fix contrib/hooks/post-receive-email hooks.recipients error message 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>	17 years ago
Andy Parkins	e6dc8d60fb	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>	17 years ago
Jim Meyering	d1637a07f6	Do not over-quote the -f envelopesender value. 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>	17 years ago
Junio C Hamano	a6080a0a44	War on whitespace 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>	18 years ago
Andy Parkins	c855195cd0	post-receive-email example hook: sed command for getting description was wrong 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>	18 years ago
Andy Parkins	024e5b31af	post-receive-email example hook: detect rewind-only updates and output 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>	18 years ago
Andy Parkins	8e404f82ab	post-receive-email example hook: fastforward should have been fast_forward Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Gerrit Pape	5850cb645d	rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email. $ 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>	18 years ago
Andy Parkins	4557e0de5b	Reimplement emailing part of hooks--update in contrib/hooks/post-receive-email 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>	18 years ago

23 Commits (dc267b1ab4f8f6ac33c9145c3e24fe3a96f1394b)