summaryrefslogtreecommitdiff
path: root/templates
AgeCommit message (Collapse)AuthorFilesLines
2008-05-21Fix prepare-commit-msg hook and replace in-place sedLibravatar Marcel Koeppen1-4/+4
The patterns to the case statement could never be matched, so the hook was a noop. This patch also replaces the non-portable use of in-place sed. Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-29Merge branch 'maint'Libravatar Junio C Hamano1-3/+3
* maint: templates/Makefile: don't depend on local umask setting Correct name of diff_flush() in API documentation Start preparing for 1.5.4.4 Conflicts: RelNotes
2008-02-28templates/Makefile: don't depend on local umask settingLibravatar Gerrit Pape1-3/+3
Don't take the local umask setting into account when installing the templates/* files and directories, running 'make install' with umask set to 077 resulted in template/* installed with permissions 700 and 600. The problem was discovered by Florian Zumbiehl, reported through http://bugs.debian.org/467518 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-06git-commit: add a prepare-commit-msg hookLibravatar Paolo Bonzini2-0/+39
The prepare-commit-msg hook is run whenever a "fresh" commit message is prepared, just before it is shown in the editor (if it is). Its purpose is to modify the commit message in-place. It takes one to three parameters. The first is the name of the file that the commit log message. The second is the source of the commit message, and can be: "message" (if a -m or -F option was given); "template" (if a -t option was given or the configuration option commit.template is set); "merge" (if the commit is a merge or a .git/MERGE_MSG file exists); "squash" (if a .git/SQUASH_MSG file exists); or "commit", followed by a commit SHA1 as the third parameter (if a -c, -C or --amend option was given). If its exit status is non-zero, git-commit will abort. The hook is not suppressed by the --no-verify option, so it should not be used as a replacement for the pre-commit hook. The sample prepare-commit-msg comments out the `Conflicts:` part of a merge's commit message; other examples are commented out, including adding a Signed-off-by line at the bottom of the commit messsage, that the user can then edit or discard altogether. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-17Officially deprecate repo-config.Libravatar Junio C Hamano1-3/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-14Make default pre-commit hook less noisyLibravatar Jean-Luc Herren1-1/+1
This hook thought to have found a conflict marker any time it saw a 7-character combination of any of the characters '<>=' at the beginning of a line, whereas it should only look for the *same* character to appear repeatedly. Also, restrict it to match exactly 7 times, to avoid matching the underlining with '='-characters often used in documentation. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-03install-sh from automake does not like -m without delimiting spaceLibravatar Robert Schiele1-1/+1
The install-sh script as shipped with automake requires a space between the -m switch and its argument. Since this is also the regular way of doing it with other install implementations this change inserts the missing space in all makefiles. Signed-off-by: Robert Schiele <rschiele@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-22Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Fix sample pre-commit hook
2007-11-22Fix sample pre-commit hookLibravatar Junio C Hamano1-1/+1
If the worktree happened to have a file called HEAD, "diff-index --cached HEAD" would complain about the ambiguity between revision and path. Avoid it by using an explicit "--" for disambiguation. 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-10-26hooks-pre-commit: use \t, rather than a literal TAB in regexpLibravatar Jim Meyering1-1/+1
Signed-off-by: Jim Meyering <meyering@redhat.com> 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-07-14Use $(RM) in Makefiles instead of 'rm -f'Libravatar Emil Medve1-1/+2
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-12Remove trailing slash from $(template_dir).Libravatar Johannes Sixt1-1/+1
All the other directory location variables do not have the trailing slash. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano4-4/+0
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-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-31Reimplement emailing part of hooks--update in contrib/hooks/post-receive-emailLibravatar Andy Parkins1-0/+17
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>
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-06Make 'make' quiet by defaultLibravatar Shawn O. Pearce1-1/+1
Per Junio's suggestion we are setting 'make' to be quiet by default, with `make V=1` available to force GNU make back to its default behavior of showing each command it is running. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-06Make 'make' quieter while building gitLibravatar Shawn O. Pearce1-3/+7
I find it difficult to see compiler warnings amongst the massive spewing produced by GNU make as it works through our productions. This is especially true if CFLAGS winds up being rather long, due to a large number of -W options being enabled and due to a number of -D options being configured/required by my platform. By defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during compilation users will get a less verbose output, such as: ... CC builtin-grep.c builtin-grep.c:187: warning: 'external_grep' defined but not used CC builtin-init-db.c CC builtin-log.c CC builtin-ls-files.c CC builtin-ls-tree.c ... The verbose (normal make) output is still the default. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 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 Roskin2-2/+2
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-12-26hooks/commit-msg: add example to add Signed-off-by line to messageLibravatar Andy Parkins1-0/+4
After checking to see if the commit message already has the target signed-off-by (for example in --amend commits), this patch generates a signed off by line from the repository owner and adds it to the commit message. Based on Johannes Schindelin's earlier patch to perform the same function. Originally, this was done in the pre-commit hook but Junio pointed out that the commit-msg hook allows the message to be edited. This has the aditional advantage that the commit-msg hook gets passed the name of the message file as a parameter, so it doesn't have to figure out GIT_DIR for itself. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19Do not create $GIT_DIR/remotes/ directory anymore.Libravatar Junio C Hamano1-1/+0
Because we do not use --no-separate-remote anymore, there is no reason to create that directory from the template. t5510 test is updated to test both $GIT_DIR/remotes/ based configuration and $GIT_DIR/config variable (credits to Johannes). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-13sample commit-msg hook: no silent exit on duplicate Signed-off-by linesLibravatar Luben Tuikov1-1/+5
git-commit would silently exit if duplicate Signed-off-by lines were found. Users of git-commit would not know it, unless they checked '$?'. This patch makes git-commit actually print out a message that nothing was commited since duplicate Signed-off-lines were found. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-13Fix regex pattern in commit-msgLibravatar Luben Tuikov1-1/+1
Between the count and the line output, some uniq(1) versions put a TAB character, not a space. Make sure both are handled. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-02Fix installation of templates on ancient systems.Libravatar Ramsay Allan Jones1-7/+5
Do not use $(call) for 'shell quoting' paths, and pass DESTDIR down to the templates makefile. [jc: we have fixed the main Makefile long time ago, but somehow forgot to apply the same fix to templates Makefile.] Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk> 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-04-19pre-commit hook: complain about conflict markers.Libravatar Junio C Hamano1-0/+3
Several <<< or === or >>> characters at the beginning of a line is very likely to be leftover conflict markers from a failed automerge the user resolved incorrectly, so detect them. As usual, this can be defeated with "git commit --no-verify" if you really do want to have those files, just like changes that introduce trailing whitespaces. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-26Merge branch 'maint'Libravatar Junio C Hamano2-0/+2
* maint: sample hooks template.
2006-02-26sample hooks template.Libravatar Junio C Hamano2-0/+2
These two sample hooks try to detect and use the corresponding commit hook from the same repository. However, they forgot to set up GIT_DIR for their own use, so was not in effect. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-13rebase: allow a hook to refuse rebasing.Libravatar Junio C Hamano1-0/+150
This lets a hook to interfere a rebase and help prevent certain branches from being rebased by mistake. A sample hook to show how to prevent a topic branch that has already been merged into publish branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29Merge fixes up to GIT 1.1.6Libravatar Junio C Hamano1-3/+10
2006-01-29[PATCH] pre-commit sample hook: do not barf on the initial importLibravatar Junio C Hamano1-3/+10
The example hook barfs on the initial import. Ideally it should produce a diff from an empty tree, but for now let's stop at squelching the bogus error message. Often an initial import involves tons of badly formatted files from foreign SCM, so not complaining about them like this patch does might actually be a better idea than enforcing the "Perfect Patch" format on them. 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-11-08Clean build annoyance.Libravatar Junio C Hamano1-1/+0
As Pasky pointed out, building in templates directory showed list of built template files which was unneeded. This commit also fixes another build annoyance I recently left in by accident. Signed-off-by: Junio C Hamano <junkio@cox.net>