Re: Problem with contrib/hooks/post-receive-email

Eli Barzilay wrote:

<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