From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Subject: Re: Problem with contrib/hooks/post-receive-email
Date: Fri, 19 Mar 2010 16:39:12 +0000 [thread overview]
Message-ID: <ho09bh$hdh$1@dough.gmane.org> (raw)
In-Reply-To: m3vdcsq0hl.fsf@winooski.ccs.neu.edu
Eli Barzilay wrote:
> The post-receive-email script goes out of its way to avoid sending
> commits twice by filtering out commits that are included in existing
> refs, but if more than one branch changes then some commits can end up
> not being reported. For example, I made two commits A and B, made one
> branch point at A and another at B, and pushed both -- neither of the
> resulting two emails had A.
<Andy starts crying>
I can't see any way to deal with this case easily with post-receive-email as
it is. It inherently processes ref-by-ref. The relevant bit of script is
in generate_update_branch_email(). The comments explain how the same
problem is addressed for another developer changing the same branch before
post-receive-email runs, but after the update is performed. I think the
same method could be applied.
git rev-parse --not --all | grep -v $(git rev-parse $refname)
This line is where the particular branches are being included and excluded.
The problem you have is that "--all" means "--all-at-the-moment", and you
want "--all-as-they-were-before-the-update".
So, --all will have to go, and a manual list built instead. The supplied
change list includes all the information necessary:
ref1_oldrev ref1_newrev ref1
ref2_oldrev ref2_newrev ref2
ref3_oldrev ref3_newrev ref3
ref4_oldrev ref4_newrev ref4
Let's say there is also a ref5 and ref6 in the repository. The revision
list we want for (say) the ref1 call to generate_email would be:
ref1_newrev
^ref2_oldrev
^ref3_oldrev
^ref4_oldrev
^ref5
^ref6
And similarly for ref2, ref3 and ref4. It seems to me that it needs a hash
table keyed on the refname, but I have no idea how to do that in bash.
%originalreftable{"ref1"} = "^ref1_oldrev"
%originalreftable{"ref2"} = "^ref2_oldrev"
%originalreftable{"ref3"} = "^ref3_oldrev"
%originalreftable{"ref4"} = "^ref4_oldrev"
%originalreftable{"ref5"} = "^ref5"
%originalreftable{"ref6"} = "^ref6"
This table would be sufficient to create the revision list for every
generate_email(), because each generate_email() knows which ref it's being
updated for, so could easily do:
%originalreftable{$myref} = "$mynewrev"
Before using the table (and restore it afterwards).
In short: yuck. It feels an awful lot like its pushing the boundaries of
what is sensible to do in shell script.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
next prev parent reply other threads:[~2010-03-19 16:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-19 6:39 Problem with contrib/hooks/post-receive-email Eli Barzilay
2010-03-19 16:39 ` Andy Parkins [this message]
2010-03-19 18:44 ` Brandon Casey
2010-03-20 3:21 ` Eli Barzilay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ho09bh$hdh$1@dough.gmane.org' \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).