This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-cvs mails for personal/vendor branches for merge commits
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, <gcc at gcc dot gnu dot org>, Joel Brobecker <brobecker at adacore dot com>
- Date: Wed, 15 Jan 2020 15:04:40 +0000
- Subject: Re: gcc-cvs mails for personal/vendor branches for merge commits
- Ironport-sdr: Jx0/GGIT6C9F+dTUOPw1D1EcgLqVpOMeD6QWiznUYw5KWOAgq0HIpUeH2sxhNMnRbj+oLYXdyN Xi84wwLHivxsKpNKSIqDZJEY7Wzxfa1ml75RCC6/j4t89PCaCQ30+AQKPnHjg0VeH/n72h+LIa ur9mNx1KM781r1eZJ6BTBsvTyTpqiu6Wed3hcMnAiN2THIUprtNbsGpCRAjBZddF5dUjcevWkr svBQ7UknM29X9k2DGcvZqc+0JzxTXVvMzlhihgYqQAaKRbzG2CHyeEelRVajE3SK/1yD6FG4Dz 0GE=
- Ironport-sdr: f/r/x08FdugGre6tihf54w8orB8KFbskYmq1JrbNMqEoBDjHrPvB2Dxc4YWEjWevCdTSMySbt3 pfIpKLIMcmnKbgmj8gepAMOd9C9+RPqUHP43YZrAD35031IvweVCCS0hm6g2cFX7jASnwBtToX ITtvNKTTWj/9RcEHoCakmOj1d+KrF3VDUMUlbsU8EHbqx3CCiojnOrdwVQt98lnEMd6m1lrFkq jP4LAYFvMoSDJKwiwjF4EuxWFwMRLlcnJf/boUYSTuIFEdL6ccSGCZrd8vpHFFX/Evli/nuolP 2x4=
- References: <20200115141617.GS10088@tucnak> <alpine.DEB.2.21.2001151448060.11538@digraph.polyomino.org.uk> <20200115150109.GU10088@tucnak>
On Wed, 15 Jan 2020, Jakub Jelinek wrote:
> On Wed, Jan 15, 2020 at 02:56:45PM +0000, Joseph Myers wrote:
> > > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> > > a simple
> > > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> > > git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> > > which merged in just a few hours from trunk, but that resulted in
> > > 20 separate mails to gcc-cvs ml.
> >
> > Joel, this is definitely a question for you; it's beyond my expertise in
> > the working of the hooks. The issue is that when a merge commit is
> > pushed, we only want mails for commits that are new *to the repository* -
> > not those that are already in the repository (accessible from some other
> > ref before the ref update being processed by the hook comes into effect),
> > but are new *to the branch*.
>
> Yeah. For release branches I think we want mails for all changes, but
> then we don't allow merge commits there; for cherry-picked patches e.g. from
> trunk to release branches we should still send mail.
A cherry-picked commit has a different commit id from the original, so is
a new commit in the repository.
Note: the old post-receive-email example hook shipped with git does the
"only commits new to the repository" thing. Its form of the logic
(function show_new_revisions) appears to be "only commits not reachable
from any ref in refs/heads", which it converts into a list of negated
revisions to pass to git rev-list when computing the new commits to show.
--
Joseph S. Myers
joseph@codesourcery.com