threads / discuss / 3095

New ref generates 8MB mail message

Subject: New ref generates 8MB mail message

## tl;dr

3 messages between Jan 18, 2006 and Jan 19, 2006.

replies: 2people: 3as markdown or json

Matthew Wilcox· Jan 18, 2006, 14:09 UTC · lore

There's a bit of an unfortunate mistake in the default mail script that causes making a new ref for Linus' kernel tree to generate an 8MB mail message.

Based on the idea that a new branch is probably a branch off master, and if it isn't, then at least sending a log vs master is better than a log vs the beginning of time, I propose this patch:

diff --git a/templates/hooks--update b/templates/hooks--update
index 6db555f..609b4fe 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -13,7 +13,7 @@ recipient="commit-list@example.com"
 if expr "$2" : '0*$' >/dev/null
 then
 	echo "Created a new ref, with the following commits:"
-	git-rev-list --pretty "$3"
+	git-rev-list --pretty "$3" ^master
 else
 	base=$(git-merge-base "$2" "$3")
 	case "$base" in
Linus Torvalds· Jan 18, 2006, 16:12 UTC · re: Matthew Wilcox · lore

Re: New ref generates 8MB mail message

On Wed, 18 Jan 2006, Matthew Wilcox wrote:
> 
> Based on the idea that a new branch is probably a branch off master, and
> if it isn't, then at least sending a log vs master is better than a log
> vs the beginning of time, I propose this patch:

Actually, since the update hook _should_ be called before the ref has actually been updated, it's probably much better to instead of this:

> -	git-rev-list --pretty "$3"
> +	git-rev-list --pretty "$3" ^master
do something like this:
	git-rev-list --pretty "$3" $(git-rev-parse --not --all)

which basically says: show any commits that are in the new ref, but are not in _any_ other ref.

Untested, of course.
		Linus
Andreas Ericsson· Jan 19, 2006, 12:35 UTC · re: Linus Torvalds · lore

Re: New ref generates 8MB mail message

Linus Torvalds wrote:
Show 25 quoted lines
> 
> On Wed, 18 Jan 2006, Matthew Wilcox wrote:
> 
>>Based on the idea that a new branch is probably a branch off master, and
>>if it isn't, then at least sending a log vs master is better than a log
>>vs the beginning of time, I propose this patch:
> 
> 
> Actually, since the update hook _should_ be called before the ref has 
> actually been updated, it's probably much better to instead of this:
> 
> 
>>-	git-rev-list --pretty "$3"
>>+	git-rev-list --pretty "$3" ^master
> 
> 
> do something like this:
> 
> 	git-rev-list --pretty "$3" $(git-rev-parse --not --all)
> 
> which basically says: show any commits that are in the new ref, but are 
> not in _any_ other ref.
> 
> Untested, of course.
> 
Tested. It works fine and is, surprisingly, insanely fast.
-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

← back to recent threads