Andy Parkins <andyparkins@xxxxxxxxx> writes:
> 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.
Well, one thing that sounded obvious to me is to expicitly say
something about it. The "danger" that I see in this is a central
repository setup and people relying on knowing everything that happens
by reading through these emails -- then get a bad surprise when
something sneaks in past those emails.
As for a proper solution, I first thought along the lines of what
Brandon suggested -- but I considered doing that with a hash table
instead of accumulating a sed script.
> 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.
> [...]
(Isn't that just associative arrays?)
> In short: yuck. It feels an awful lot like its pushing the
> boundaries of what is sensible to do in shell script.
Yeah, my conclusion was similar... But after considering it for a
while, I think that a saner approach is to choose a main branch (eg,
`master' or `devel') where all commits are always reported, then for
branches show only commits that are not on this main branch. This
means that if you only read the emails on this branch you know
practically everything that happens, and if you're interested in what
happens on a branch you will see some commits again in the future when
they're added to the main branch -- but that seems even better to me:
even I read some commit when it happened on a branch, I'd still want
to know when it's added to the main branch.
This seems to me both more predictable in the sense of the
notifications and the code. But I'm in the process of converting a
project to git so I might not be experienced enough...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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