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@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html