* gcc-cvs mails for personal/vendor branches for merge commits @ 2020-01-15 15:07 Jakub Jelinek 2020-01-15 15:42 ` Joseph Myers 0 siblings, 1 reply; 30+ messages in thread From: Jakub Jelinek @ 2020-01-15 15:07 UTC (permalink / raw) To: Joseph S. Myers, Richard Earnshaw (lists); +Cc: gcc Hi! 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. Is that what we want? I mean it doesn't scale well, even if everybody has just a couple of personal branches + few vendor branches for all, if some of them will be tracking master or release branches, if each such push pushes all the commits again, there will be tens of thousands of mails. And forcing everybody to squash all merge commits because of this is undesirable. Could we somehow detect merges from other branches (or say only master or release branches) and don't send mails for those and send just a mail for the merge commit? Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? Jakub ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 15:07 gcc-cvs mails for personal/vendor branches for merge commits Jakub Jelinek @ 2020-01-15 15:42 ` Joseph Myers 2020-01-15 15:51 ` Jakub Jelinek ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Joseph Myers @ 2020-01-15 15:42 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Earnshaw (lists), gcc, Joel Brobecker On Wed, 15 Jan 2020, Jakub Jelinek wrote: > Hi! > > 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*. I think there's a similar issue not just for merges but for non-fast-forward pushes as well. As a glibc example, consider <https://sourceware.org/ml/glibc-cvs/2019-q4/msg00666.html> and the long series of subsequent mails in the glibc-cvs archives. It's correct that the five or so rebased patches on the branch got mailed out again. It's *not* desirable that the 50 or so patches that were already on master, that the branch got rebased on top of, got mailed out again. > Is that what we want? I mean it doesn't scale well, even if everybody has > just a couple of personal branches + few vendor branches for all, if some of > them will be tracking master or release branches, if each such push > pushes all the commits again, there will be tens of thousands of mails. > And forcing everybody to squash all merge commits because of this is > undesirable. > Could we somehow detect merges from other branches (or say only master or > release branches) and don't send mails for those and send just a mail for > the merge commit? > Or, if that is not possible, disable gcc-cvs mail for vendor and private > branches altogether? -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 15:42 ` Joseph Myers @ 2020-01-15 15:51 ` Jakub Jelinek 2020-01-15 16:01 ` Joseph Myers 2020-01-15 16:42 ` Jason Merrill 2020-01-16 14:28 ` Joel Brobecker 2 siblings, 1 reply; 30+ messages in thread From: Jakub Jelinek @ 2020-01-15 15:51 UTC (permalink / raw) To: Joseph Myers; +Cc: Richard Earnshaw (lists), gcc, Joel Brobecker 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. > I think there's a similar issue not just for merges but for > non-fast-forward pushes as well. As a glibc example, consider > <https://sourceware.org/ml/glibc-cvs/2019-q4/msg00666.html> and the long > series of subsequent mails in the glibc-cvs archives. It's correct that > the five or so rebased patches on the branch got mailed out again. It's > *not* desirable that the 50 or so patches that were already on master, > that the branch got rebased on top of, got mailed out again. Jakub ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 15:51 ` Jakub Jelinek @ 2020-01-15 16:01 ` Joseph Myers 0 siblings, 0 replies; 30+ messages in thread From: Joseph Myers @ 2020-01-15 16:01 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Earnshaw (lists), gcc, Joel Brobecker 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 15:42 ` Joseph Myers 2020-01-15 15:51 ` Jakub Jelinek @ 2020-01-15 16:42 ` Jason Merrill 2020-01-15 16:58 ` Joseph Myers 2020-01-16 14:28 ` Joel Brobecker 2 siblings, 1 reply; 30+ messages in thread From: Jason Merrill @ 2020-01-15 16:42 UTC (permalink / raw) To: Joseph Myers, Jakub Jelinek; +Cc: Richard Earnshaw (lists), gcc, Joel Brobecker On 1/15/20 9:56 AM, Joseph Myers wrote: > On Wed, 15 Jan 2020, Jakub Jelinek wrote: > >> Or, if that is not possible, disable gcc-cvs mail for vendor and private >> branches altogether? I think this is desirable. gcc-cvs should only mail about changes to master and release branches. Jason ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 16:42 ` Jason Merrill @ 2020-01-15 16:58 ` Joseph Myers 2020-01-15 17:09 ` Jason Merrill ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Joseph Myers @ 2020-01-15 16:58 UTC (permalink / raw) To: Jason Merrill Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc, Joel Brobecker On Wed, 15 Jan 2020, Jason Merrill wrote: > On 1/15/20 9:56 AM, Joseph Myers wrote: > > On Wed, 15 Jan 2020, Jakub Jelinek wrote: > > > > > Or, if that is not possible, disable gcc-cvs mail for vendor and private > > > branches altogether? > > I think this is desirable. gcc-cvs should only mail about changes to master > and release branches. I thinks commit mails for changes to all branches are desirable (including refs/heads/devel/ branches, including user and vendor branches) - but they should only be for changes that are new to the repository. Existing practice in SVN was that all branches generated mails, we simply didn't have so many branches. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 16:58 ` Joseph Myers @ 2020-01-15 17:09 ` Jason Merrill 2020-01-15 17:57 ` Iain Sandoe 2020-01-15 19:21 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 30+ messages in thread From: Jason Merrill @ 2020-01-15 17:09 UTC (permalink / raw) To: Joseph Myers; +Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc, Joel Brobecker On 1/15/20 11:30 AM, Joseph Myers wrote: > On Wed, 15 Jan 2020, Jason Merrill wrote: > >> On 1/15/20 9:56 AM, Joseph Myers wrote: >>> On Wed, 15 Jan 2020, Jakub Jelinek wrote: >>> >>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private >>>> branches altogether? >> >> I think this is desirable. gcc-cvs should only mail about changes to master >> and release branches. > > I thinks commit mails for changes to all branches are desirable (including > refs/heads/devel/ branches, including user and vendor branches) - but they > should only be for changes that are new to the repository. Existing > practice in SVN was that all branches generated mails, we simply didn't > have so many branches. User branches in particular are likely to be very messy in the git world; in the old git mirror I would occasionally push a personal branch with work-in-progress patches that aren't nicely organized. Perhaps one mail per push for those branches, rather than one per commit? Jason ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 16:58 ` Joseph Myers 2020-01-15 17:09 ` Jason Merrill @ 2020-01-15 17:57 ` Iain Sandoe 2020-01-15 20:20 ` Jason Merrill 2020-01-19 14:10 ` Segher Boessenkool 2020-01-15 19:21 ` Richard Earnshaw (lists) 2 siblings, 2 replies; 30+ messages in thread From: Iain Sandoe @ 2020-01-15 17:57 UTC (permalink / raw) To: Joseph Myers Cc: Jason Merrill, Jakub Jelinek, Richard Earnshaw (lists), gcc, Joel Brobecker Joseph Myers <joseph@codesourcery.com> wrote: > On Wed, 15 Jan 2020, Jason Merrill wrote: > >> On 1/15/20 9:56 AM, Joseph Myers wrote: >>> On Wed, 15 Jan 2020, Jakub Jelinek wrote: >>> >>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private >>>> branches altogether? >> >> I think this is desirable. gcc-cvs should only mail about changes to master >> and release branches. > > I thinks commit mails for changes to all branches are desirable (including > refs/heads/devel/ branches, including user and vendor branches) - but they > should only be for changes that are new to the repository. Existing > practice in SVN was that all branches generated mails, we simply didn't > have so many branches. For user/vendor branches that are rebased (a desirable action), is there any mechanism for excluding unchanged rebased commits from being seen as ânewâ? Iâm guessing that public development branches will probably gravitate to the no non-FF mode, if they are to be used by people other than the primary author .. although that does somewhat limit things; rebasing WIP onto trunk and reorganising / squashing is useful as well. Iain ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 17:57 ` Iain Sandoe @ 2020-01-15 20:20 ` Jason Merrill 2020-01-19 14:10 ` Segher Boessenkool 1 sibling, 0 replies; 30+ messages in thread From: Jason Merrill @ 2020-01-15 20:20 UTC (permalink / raw) To: Iain Sandoe, Joseph Myers Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc, Joel Brobecker On 1/15/20 11:37 AM, Iain Sandoe wrote: > Joseph Myers <joseph@codesourcery.com> wrote: > >> On Wed, 15 Jan 2020, Jason Merrill wrote: >> >>> On 1/15/20 9:56 AM, Joseph Myers wrote: >>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote: >>>> >>>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private >>>>> branches altogether? >>> >>> I think this is desirable. gcc-cvs should only mail about changes to master >>> and release branches. >> >> I thinks commit mails for changes to all branches are desirable (including >> refs/heads/devel/ branches, including user and vendor branches) - but they >> should only be for changes that are new to the repository. Existing >> practice in SVN was that all branches generated mails, we simply didn't >> have so many branches. > > For user/vendor branches that are rebased (a desirable action), is there any > mechanism for excluding unchanged rebased commits from being seen as > “new”? > > I’m guessing that public development branches will probably gravitate to the > no non-FF mode, if they are to be used by people other than the primary author Except that long-lived public development branches will need to merge master periodically, and that will be a non-FF merge. Jason ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 17:57 ` Iain Sandoe 2020-01-15 20:20 ` Jason Merrill @ 2020-01-19 14:10 ` Segher Boessenkool 2020-01-19 22:40 ` Julien "_FrnchFrgg_" Rivaud 1 sibling, 1 reply; 30+ messages in thread From: Segher Boessenkool @ 2020-01-19 14:10 UTC (permalink / raw) To: Iain Sandoe Cc: Joseph Myers, Jason Merrill, Jakub Jelinek, Richard Earnshaw (lists), gcc, Joel Brobecker On Wed, Jan 15, 2020 at 04:37:49PM +0000, Iain Sandoe wrote: > Iâm guessing that public development branches will probably gravitate to the > no non-FF mode, if they are to be used by people other than the primary author > > .. although that does somewhat limit things; rebasing WIP onto trunk and > reorganising / squashing is useful as well. If a branch does rebase all people who commit to it need to make sure not to overwrite others' work. Your pushes are always non-fast-forward, so you do not notice you did not incorporate someone else's new work if you do not take care. One easy way to avoid this is to just have only one person pushing to a certain branch. Segher ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-19 14:10 ` Segher Boessenkool @ 2020-01-19 22:40 ` Julien "_FrnchFrgg_" Rivaud 2020-01-20 18:42 ` Segher Boessenkool 0 siblings, 1 reply; 30+ messages in thread From: Julien "_FrnchFrgg_" Rivaud @ 2020-01-19 22:40 UTC (permalink / raw) To: gcc Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : > On Wed, Jan 15, 2020 at 04:37:49PM +0000, Iain Sandoe wrote: >> Iâm guessing that public development branches will probably gravitate to the >> no non-FF mode, if they are to be used by people other than the primary author >> >> .. although that does somewhat limit things; rebasing WIP onto trunk and >> reorganising / squashing is useful as well. > > If a branch does rebase all people who commit to it need to make sure > not to overwrite others' work. Your pushes are always non-fast-forward, > so you do not notice you did not incorporate someone else's new work if > you do not take care. There is the git push --force-with-lease option to avoid that. Its goal is to force a non-fast-forward push, but only if the remote position (HEAD) is actually where you expect it to, that is no work you don't know about has been pushed in the mean time. I strongly recommend to use --force-with-lease on non-user branches. User branches you usually control totally and are the only one to push to, so that's less an issue. > > One easy way to avoid this is to just have only one person pushing to a > certain branch. > > > Segher > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-19 22:40 ` Julien "_FrnchFrgg_" Rivaud @ 2020-01-20 18:42 ` Segher Boessenkool 0 siblings, 0 replies; 30+ messages in thread From: Segher Boessenkool @ 2020-01-20 18:42 UTC (permalink / raw) To: Julien _FrnchFrgg_ Rivaud; +Cc: gcc [ Please do reply to me when you reply to my mails. Maybe gmane did that? Yet Another reason not to use gmane. ] On Sat, Jan 18, 2020 at 11:04:12PM +0100, Julien _FrnchFrgg_ Rivaud wrote: > Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : > >If a branch does rebase all people who commit to it need to make sure > >not to overwrite others' work. Your pushes are always non-fast-forward, > >so you do not notice you did not incorporate someone else's new work if > >you do not take care. > > There is the git push --force-with-lease option to avoid that. Its goal > is to force a non-fast-forward push, but only if the remote position > (HEAD) is actually where you expect it to, that is no work you don't > know about has been pushed in the mean time. > > I strongly recommend to use --force-with-lease on non-user branches. > User branches you usually control totally and are the only one to push > to, so that's less an issue. Sure, that option helps to avoid problems when you do the wrong thing. But you still need a plan what to do when there *are* problems, or to avoid such problems in the first place. You need some policy for when the branch is rebased, and who does that, and how the other users are supposed to learn about this. (Using merges avoids this, it always makes a mess, instead it postpones all the "make it a clean patch series" work to later.) Segher ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 16:58 ` Joseph Myers 2020-01-15 17:09 ` Jason Merrill 2020-01-15 17:57 ` Iain Sandoe @ 2020-01-15 19:21 ` Richard Earnshaw (lists) 2020-01-16 9:55 ` Joseph Myers 2 siblings, 1 reply; 30+ messages in thread From: Richard Earnshaw (lists) @ 2020-01-15 19:21 UTC (permalink / raw) To: Joseph Myers, Jason Merrill; +Cc: Jakub Jelinek, gcc, Joel Brobecker On 15/01/2020 16:30, Joseph Myers wrote: > On Wed, 15 Jan 2020, Jason Merrill wrote: > >> On 1/15/20 9:56 AM, Joseph Myers wrote: >>> On Wed, 15 Jan 2020, Jakub Jelinek wrote: >>> >>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private >>>> branches altogether? >> >> I think this is desirable. gcc-cvs should only mail about changes to master >> and release branches. > > I thinks commit mails for changes to all branches are desirable (including > refs/heads/devel/ branches, including user and vendor branches) - but they > should only be for changes that are new to the repository. Existing > practice in SVN was that all branches generated mails, we simply didn't > have so many branches. > How about separate email list(s) for the vendor and personal spaces? I do think changes there should be visible, but perhaps fewer folk will be interested in tracking them at the same level. R. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 19:21 ` Richard Earnshaw (lists) @ 2020-01-16 9:55 ` Joseph Myers 0 siblings, 0 replies; 30+ messages in thread From: Joseph Myers @ 2020-01-16 9:55 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Jakub Jelinek, gcc, Joel Brobecker On Wed, 15 Jan 2020, Richard Earnshaw (lists) wrote: > How about separate email list(s) for the vendor and personal spaces? I do > think changes there should be visible, but perhaps fewer folk will be > interested in tracking them at the same level. That's currently documented as a feature not supported by the hooks (the script to determine the lists to use only receives information about the files changed, not about the refs being updated). I've now filed issues at https://github.com/AdaCore/git-hooks/issues for what I think are all the feature requests we have so far for making the hooks more configurable so particular features of use to GCC can be implemented without needing to patch the hooks themselves as at present. If you have a feature request of the form "the hooks should allow configuring X" it probably makes sense to file it there to help Joel track it. However, policy questions about how we should configure the hooks for GCC (whether or not they depend on new hook features) would best be discussed here. I'll add a check to the GCC hooks for commit messages whose first line is a single word, to prevent pushing commits whose summary is just "gcc/ChangeLog:" or similar. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-15 15:42 ` Joseph Myers 2020-01-15 15:51 ` Jakub Jelinek 2020-01-15 16:42 ` Jason Merrill @ 2020-01-16 14:28 ` Joel Brobecker 2020-01-16 14:35 ` Jakub Jelinek 2020-01-16 18:58 ` Joseph Myers 2 siblings, 2 replies; 30+ messages in thread From: Joel Brobecker @ 2020-01-16 14:28 UTC (permalink / raw) To: Joseph Myers; +Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc > 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*. We used to have that kind of behavior, and found that this was causing problems. The main problem is when you are merging a branch for which for which a no-email policy applies to a branch for which the normal emails are to be sent. This happens for instance when people used development branches that they had silenced so as to avoid spamming people. And because they have been rebasing their branch regularly, the "merge" ended up being a fast-forward. And because it was a fast forward, the hooks saw that the commits were already known to the repository, and no email was sent at all for those new commits. Beyond this specific issue of users being surprised about the missing emails, we thought about it more, and it seemed logical that we would want a trace for each branch a commit makes it to. It's an essential element of being able to track where a given commit was applied. > I think there's a similar issue not just for merges but for > non-fast-forward pushes as well. As a glibc example, consider > <https://sourceware.org/ml/glibc-cvs/2019-q4/msg00666.html> and the long > series of subsequent mails in the glibc-cvs archives. It's correct that > the five or so rebased patches on the branch got mailed out again. It's > *not* desirable that the 50 or so patches that were already on master, > that the branch got rebased on top of, got mailed out again. At heart, it is really the same issue. New commits were brought into this branch, and thus if email notification is enabled for that branch, then those commits should trigger emails for their own as well. Typically, branches were non-fast-forward changes are allowed are branches that are personal and not shared. In those instances, the typical setup is to disable emails on those development branches. It sounds to me like turning emails off for branches that can do non-fast-forward is the better solution here. -- Joel ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-16 14:28 ` Joel Brobecker @ 2020-01-16 14:35 ` Jakub Jelinek 2020-01-16 14:43 ` Richard Earnshaw (lists) 2020-01-16 22:03 ` Joseph Myers 2020-01-16 18:58 ` Joseph Myers 1 sibling, 2 replies; 30+ messages in thread From: Jakub Jelinek @ 2020-01-16 14:35 UTC (permalink / raw) To: Joel Brobecker; +Cc: Joseph Myers, Richard Earnshaw (lists), gcc On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote: > > I think there's a similar issue not just for merges but for > > non-fast-forward pushes as well. As a glibc example, consider > > <https://sourceware.org/ml/glibc-cvs/2019-q4/msg00666.html> and the long > > series of subsequent mails in the glibc-cvs archives. It's correct that > > the five or so rebased patches on the branch got mailed out again. It's > > *not* desirable that the 50 or so patches that were already on master, > > that the branch got rebased on top of, got mailed out again. > > At heart, it is really the same issue. New commits were brought into > this branch, and thus if email notification is enabled for that branch, > then those commits should trigger emails for their own as well. > > Typically, branches were non-fast-forward changes are allowed are > branches that are personal and not shared. In those instances, > the typical setup is to disable emails on those development branches. > It sounds to me like turning emails off for branches that can > do non-fast-forward is the better solution here. Couldn't it be then per-branch setting, whether to mail even commits that aren't new to the repository or not (like I understood it is already possible to decide per-branch whether to send mails at all)? E.g. for GCC, I'd certainly like to see mails for all commits on the trunk and release branches (but we don't allow merge commits on them anyway), and for other branches (personal, vendor, devel) I think mailing only about new commits not already in the repository would be better over not mailing at all. Jakub ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-16 14:35 ` Jakub Jelinek @ 2020-01-16 14:43 ` Richard Earnshaw (lists) 2020-01-16 18:51 ` Jakub Jelinek 2020-01-16 22:03 ` Joseph Myers 1 sibling, 1 reply; 30+ messages in thread From: Richard Earnshaw (lists) @ 2020-01-16 14:43 UTC (permalink / raw) To: Jakub Jelinek, Joel Brobecker; +Cc: Joseph Myers, gcc On 16/01/2020 14:11, Jakub Jelinek wrote: > On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote: >>> I think there's a similar issue not just for merges but for >>> non-fast-forward pushes as well. As a glibc example, consider >>> <https://sourceware.org/ml/glibc-cvs/2019-q4/msg00666.html> and the long >>> series of subsequent mails in the glibc-cvs archives. It's correct that >>> the five or so rebased patches on the branch got mailed out again. It's >>> *not* desirable that the 50 or so patches that were already on master, >>> that the branch got rebased on top of, got mailed out again. >> >> At heart, it is really the same issue. New commits were brought into >> this branch, and thus if email notification is enabled for that branch, >> then those commits should trigger emails for their own as well. >> >> Typically, branches were non-fast-forward changes are allowed are >> branches that are personal and not shared. In those instances, >> the typical setup is to disable emails on those development branches. >> It sounds to me like turning emails off for branches that can >> do non-fast-forward is the better solution here. > > Couldn't it be then per-branch setting, whether to mail even commits > that aren't new to the repository or not (like I understood it is already > possible to decide per-branch whether to send mails at all)? > E.g. for GCC, I'd certainly like to see mails for all commits on the > trunk and release branches (but we don't allow merge commits on them > anyway), and for other branches (personal, vendor, devel) I think mailing > only about new commits not already in the repository would be better over > not mailing at all. > > Jakub > The alternative I suggested to Joseph yesterday was a separate mailing list for all the personal and vendor commits. But I think that would need a change to the hooks infrastructure. R. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-16 14:43 ` Richard Earnshaw (lists) @ 2020-01-16 18:51 ` Jakub Jelinek 0 siblings, 0 replies; 30+ messages in thread From: Jakub Jelinek @ 2020-01-16 18:51 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: Joel Brobecker, Joseph Myers, gcc On Thu, Jan 16, 2020 at 02:15:21PM +0000, Richard Earnshaw (lists) wrote: > The alternative I suggested to Joseph yesterday was a separate mailing list > for all the personal and vendor commits. But I think that would need a > change to the hooks infrastructure. Would that solve it? We have around 7500 to 8000 trunk commits a year lately, so on the trunk+release branch mailing list it would be say 12000 mails a year, but if there are say 30 long lived devel/personal/vendor branches that track trunk that would already mean 240000 mails alone in those merge commits. Sure, for branches tracking release branches it will be less than that. As a random sample, I've picked a random gcc trunk test added in June and it got merged into 5 tracking branches later on 6 branches tracking release branches. That was with svn (but that one sent one mail per merge, not hundreds), but git encourages that people push their devel branches upstream. Jakub ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-16 14:35 ` Jakub Jelinek 2020-01-16 14:43 ` Richard Earnshaw (lists) @ 2020-01-16 22:03 ` Joseph Myers 1 sibling, 0 replies; 30+ messages in thread From: Joseph Myers @ 2020-01-16 22:03 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Joel Brobecker, Richard Earnshaw (lists), gcc On Thu, 16 Jan 2020, Jakub Jelinek wrote: > Couldn't it be then per-branch setting, whether to mail even commits > that aren't new to the repository or not (like I understood it is already > possible to decide per-branch whether to send mails at all)? Feel free to add such suggestions to the issues at <https://github.com/AdaCore/git-hooks/issues> (this one is <https://github.com/AdaCore/git-hooks/issues/9>). Those issues are meant to track all the cases where we think some changes to the hooks would be useful for GCC (whether or not we've currently addressed them with local changes to the hooks). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-16 14:28 ` Joel Brobecker 2020-01-16 14:35 ` Jakub Jelinek @ 2020-01-16 18:58 ` Joseph Myers 2020-01-17 16:47 ` Joel Brobecker 1 sibling, 1 reply; 30+ messages in thread From: Joseph Myers @ 2020-01-16 18:58 UTC (permalink / raw) To: Joel Brobecker; +Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc On Thu, 16 Jan 2020, Joel Brobecker wrote: > emails are to be sent. This happens for instance when people used > development branches that they had silenced so as to avoid spamming > people. And because they have been rebasing their branch regularly, > the "merge" ended up being a fast-forward. And because it was a fast > forward, the hooks saw that the commits were already known to the > repository, and no email was sent at all for those new commits. The approach used by post-receive-email is to send a summary email but without resending the already-sent commits. That seems appropriate to me. > Beyond this specific issue of users being surprised about the missing > emails, we thought about it more, and it seemed logical that we would > want a trace for each branch a commit makes it to. It's an essential > element of being able to track where a given commit was applied. A summary email just listing the commits merged seems much better than sending email maybe dozens of times for every commit to master. > Typically, branches were non-fast-forward changes are allowed are > branches that are personal and not shared. In those instances, > the typical setup is to disable emails on those development branches. > It sounds to me like turning emails off for branches that can > do non-fast-forward is the better solution here. I think it's desirable for development that *happens on* the personal and vendor branches to be visible in gcc-cvs - that is different from things getting merged into them. Likewise for the refs/heads/devel/* development branches - non-fast-forward pushes are not permitted there, but such branches can expect to have lots of merges from master, and it's the actual development taking place *on* the branches - the new commits - that is of interest to see on gcc-cvs, not the merging of existing commits. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-16 18:58 ` Joseph Myers @ 2020-01-17 16:47 ` Joel Brobecker 2020-01-17 17:22 ` Iain Sandoe 2020-01-17 17:23 ` Joseph Myers 0 siblings, 2 replies; 30+ messages in thread From: Joel Brobecker @ 2020-01-17 16:47 UTC (permalink / raw) To: Joseph Myers; +Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc > I think it's desirable for development that *happens on* the personal and > vendor branches to be visible in gcc-cvs - that is different from things > getting merged into them. > > Likewise for the refs/heads/devel/* development branches - > non-fast-forward pushes are not permitted there, but such branches can > expect to have lots of merges from master, and it's the actual development > taking place *on* the branches - the new commits - that is of interest to > see on gcc-cvs, not the merging of existing commits. Would it be sufficient to say that some branches would only trigger a summary email, but not individual commit emails? The downside is that you would not be getting the "diff" for commits that are really completely new. But on the other hand, it would fit better with the fact that user branches could have frequent re-basing, thus causing the same commit email being sent over and over at each rebase operation. It would also answer the issue of the number of emails being sent when people are doing a merge which brings in more commits than the max-emails number. -- Joel ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 16:47 ` Joel Brobecker @ 2020-01-17 17:22 ` Iain Sandoe 2020-01-17 17:59 ` Joel Brobecker 2020-01-17 17:23 ` Joseph Myers 1 sibling, 1 reply; 30+ messages in thread From: Iain Sandoe @ 2020-01-17 17:22 UTC (permalink / raw) To: Joel Brobecker; +Cc: Joseph Myers, Jakub Jelinek, Richard Earnshaw (lists), gcc Joel Brobecker <brobecker@adacore.com> wrote: >> I think it's desirable for development that *happens on* the personal and >> vendor branches to be visible in gcc-cvs - that is different from things >> getting merged into them. >> >> Likewise for the refs/heads/devel/* development branches - >> non-fast-forward pushes are not permitted there, but such branches can >> expect to have lots of merges from master, and it's the actual development >> taking place *on* the branches - the new commits - that is of interest to >> see on gcc-cvs, not the merging of existing commits. > > Would it be sufficient to say that some branches would only > trigger a summary email, but not individual commit emails? > The downside is that you would not be getting the "diff" for > commits that are really completely new. But on the other hand, > it would fit better with the fact that user branches could have > frequent re-basing, thus causing the same commit email being sent > over and over at each rebase operation. It would also answer > the issue of the number of emails being sent when people are doing > a merge which brings in more commits than the max-emails number. AFAIU, we have access to more fine-grained information; isnât it possible to differentiate ânewâ commits, from âmergesâ and from ârebasesâ? (because a ânewâ commit does not have the extra fields set up for merges and rebases). For example, Iâd like to know that user/fred has rebased the branch iâm interested in but OTOH, would not find the per-commit mails useful (so a summary there is good). If a push contains a combination of things - new work, merged and rebased commits - then there would have to be some way to react to split or aggregate the messages / diffs per commit id. Iain ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 17:22 ` Iain Sandoe @ 2020-01-17 17:59 ` Joel Brobecker 2020-01-17 19:15 ` Jason Merrill 0 siblings, 1 reply; 30+ messages in thread From: Joel Brobecker @ 2020-01-17 17:59 UTC (permalink / raw) To: Iain Sandoe; +Cc: Joseph Myers, Jakub Jelinek, Richard Earnshaw (lists), gcc > AFAIU, we have access to more fine-grained information; isnât it possible > to differentiate ânewâ commits, from âmergesâ and from ârebasesâ? > (because a ânewâ commit does not have the extra fields set up for merges > and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. > For example, Iâd like to know that user/fred has rebased the branch iâm > interested in but OTOH, would not find the per-commit mails useful (so a > summary there is good). > > If a push contains a combination of things - new work, merged and rebased > commits - then there would have to be some way to react to split or aggregate > the messages / diffs per commit id. -- Joel ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 17:59 ` Joel Brobecker @ 2020-01-17 19:15 ` Jason Merrill 2020-01-17 22:39 ` Joel Brobecker 0 siblings, 1 reply; 30+ messages in thread From: Jason Merrill @ 2020-01-17 19:15 UTC (permalink / raw) To: Joel Brobecker, Iain Sandoe Cc: Joseph Myers, Jakub Jelinek, Richard Earnshaw (lists), gcc On 1/17/20 11:55 AM, Joel Brobecker wrote: >> AFAIU, we have access to more fine-grained information; isn’t it possible >> to differentiate “new” commits, from ‘merges’ and from ‘rebases’? >> (because a ‘new’ commit does not have the extra fields set up for merges >> and rebases). > > In my opinion, this would create a lot of complication for the benefits > being gained. I also think that the more variations of behaviors you > introduce, the harder is becomes for people to know what's right and > what's not expected. People then start getting surprised and start > asking about it. At best, it's just a quick answer, but in some cases, > it takes time to remember why we set things up the way they are and why > it doesn't make sense to change it. Over the years, I have really learnt > to enjoy the benefits of consistency, even if it is means some areas > are suboptimal. The "suboptimality" can still be a better compromise > overall than a superengineered system. Spamming the list with emails every time someone merges master to their development branch sounds highly suboptimal, and likely to lead to disabling email entirely for those branches. Is it so complicated to send a single email for a merge commit or non-fast-forward push? Jason ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 19:15 ` Jason Merrill @ 2020-01-17 22:39 ` Joel Brobecker 2020-01-18 9:50 ` Iain Sandoe 2020-01-18 14:30 ` Joseph Myers 0 siblings, 2 replies; 30+ messages in thread From: Joel Brobecker @ 2020-01-17 22:39 UTC (permalink / raw) To: Jason Merrill Cc: Iain Sandoe, Joseph Myers, Jakub Jelinek, Richard Earnshaw (lists), gcc > > > AFAIU, we have access to more fine-grained information; isnât it possible > > > to differentiate ânewâ commits, from âmergesâ and from ârebasesâ? > > > (because a ânewâ commit does not have the extra fields set up for merges > > > and rebases). > > > > In my opinion, this would create a lot of complication for the benefits > > being gained. I also think that the more variations of behaviors you > > introduce, the harder is becomes for people to know what's right and > > what's not expected. People then start getting surprised and start > > asking about it. At best, it's just a quick answer, but in some cases, > > it takes time to remember why we set things up the way they are and why > > it doesn't make sense to change it. Over the years, I have really learnt > > to enjoy the benefits of consistency, even if it is means some areas > > are suboptimal. The "suboptimality" can still be a better compromise > > overall than a superengineered system. > > Spamming the list with emails every time someone merges master to their > development branch sounds highly suboptimal, and likely to lead to disabling > email entirely for those branches. Is it so complicated to send a single > email for a merge commit or non-fast-forward push? Well, no. I was going so say that this is what I have been proposing all along, except the way you phrased your suggestion above makes me think that perhaps you want something more automatic, where the hooks decide dynamically, rather than the choice being made by configuration. So it's not exactly the same, but quite similar in spirit. I think we can find ways that will satisfy the need for fewer emails without having to have that extra logic, though. Also, you guys have to understand that you are all coming to me from multiple directions at the same time, and making requests that are not always easy to reconcile. I do completely understand that getting hundreds of emails because of a merge into a development branch is far from optimal, and it's absolutely not what I am suggesting we do here. In fact, you'll see that I told Joseph in a separate mail that I will think this over and try to come up with something that answers the situation he described. What I am alerting people to is trying to have special-case handling for every scenario we can conceive. I'm wondering if we wouldn't be better off having this discussion live over a meeting or a series of meetings... -- Joel ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 22:39 ` Joel Brobecker @ 2020-01-18 9:50 ` Iain Sandoe 2020-01-18 11:07 ` Jason Merrill 2020-01-18 14:30 ` Joseph Myers 1 sibling, 1 reply; 30+ messages in thread From: Iain Sandoe @ 2020-01-18 9:50 UTC (permalink / raw) To: Joel Brobecker Cc: Jason Merrill, Joseph Myers, Jakub Jelinek, Richard Earnshaw (lists), gcc Joel Brobecker <brobecker@adacore.com> wrote: >>>> AFAIU, we have access to more fine-grained information; isnât it >>>> possible >>>> to differentiate ânewâ commits, from âmergesâ and from ârebasesâ? >>>> (because a ânewâ commit does not have the extra fields set up for merges >>>> and rebases). >>> >>> In my opinion, this would create a lot of complication for the benefits >>> being gained. I also think that the more variations of behaviors you >>> introduce, the harder is becomes for people to know what's right and >>> what's not expected. People then start getting surprised and start >>> asking about it. At best, it's just a quick answer, but in some cases, >>> it takes time to remember why we set things up the way they are and why >>> it doesn't make sense to change it. Over the years, I have really learnt >>> to enjoy the benefits of consistency, even if it is means some areas >>> are suboptimal. The "suboptimality" can still be a better compromise >>> overall than a superengineered system. >> >> Spamming the list with emails every time someone merges master to their >> development branch sounds highly suboptimal, and likely to lead to >> disabling >> email entirely for those branches. Is it so complicated to send a single >> email for a merge commit or non-fast-forward push? > > Well, no. I was going so say that this is what I have been proposing > all along, except the way you phrased your suggestion above makes > me think that perhaps you want something more automatic, where the hooks > decide dynamically, rather than the choice being made by configuration. > So it's not exactly the same, but quite similar in spirit. I think > we can find ways that will satisfy the need for fewer emails without > having to have that extra logic, though. > > Also, you guys have to understand that you are all coming to me from > multiple directions at the same time, and making requests that are > not always easy to reconcile. I do completely understand that getting > hundreds of emails because of a merge into a development branch is far > from optimal, and it's absolutely not what I am suggesting we do here. > In fact, you'll see that I told Joseph in a separate mail that I will > think this over and try to come up with something that answers the > situation he described. What I am alerting people to is trying to > have special-case handling for every scenario we can conceive. for my part, I was not trying to specify ârequirementsâ - but identify different scenarios that we might want to handle (better to decide how we want to do things at the start, than to create changes later). As a general rule, Iâm 100% in favour of KISS. > I'm wondering if we wouldn't be better off having this discussion live > over a meeting or a series of meetings⦠could be, Iain ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-18 9:50 ` Iain Sandoe @ 2020-01-18 11:07 ` Jason Merrill 0 siblings, 0 replies; 30+ messages in thread From: Jason Merrill @ 2020-01-18 11:07 UTC (permalink / raw) To: Iain Sandoe, Joel Brobecker Cc: Joseph Myers, Jakub Jelinek, Richard Earnshaw (lists), gcc On 1/17/20 12:59 PM, Iain Sandoe wrote: > Joel Brobecker <brobecker@adacore.com> wrote: > >>>>> AFAIU, we have access to more fine-grained information; isn’t it possible >>>>> to differentiate “new” commits, from ‘merges’ and from ‘rebases’? >>>>> (because a ‘new’ commit does not have the extra fields set up for merges >>>>> and rebases). >>>> >>>> In my opinion, this would create a lot of complication for the benefits >>>> being gained. I also think that the more variations of behaviors you >>>> introduce, the harder is becomes for people to know what's right and >>>> what's not expected. People then start getting surprised and start >>>> asking about it. At best, it's just a quick answer, but in some cases, >>>> it takes time to remember why we set things up the way they are and why >>>> it doesn't make sense to change it. Over the years, I have really >>>> learnt >>>> to enjoy the benefits of consistency, even if it is means some areas >>>> are suboptimal. The "suboptimality" can still be a better compromise >>>> overall than a superengineered system. >>> >>> Spamming the list with emails every time someone merges master to their >>> development branch sounds highly suboptimal, and likely to lead to disabling >>> email entirely for those branches. Is it so complicated to send a single >>> email for a merge commit or non-fast-forward push? >> >> Well, no. I was going so say that this is what I have been proposing >> all along, except the way you phrased your suggestion above makes >> me think that perhaps you want something more automatic, where the hooks >> decide dynamically, rather than the choice being made by configuration. >> So it's not exactly the same, but quite similar in spirit. I think >> we can find ways that will satisfy the need for fewer emails without >> having to have that extra logic, though. >> >> Also, you guys have to understand that you are all coming to me from >> multiple directions at the same time, and making requests that are >> not always easy to reconcile. I do completely understand that getting >> hundreds of emails because of a merge into a development branch is far >> from optimal, and it's absolutely not what I am suggesting we do here. >> In fact, you'll see that I told Joseph in a separate mail that I will >> think this over and try to come up with something that answers the >> situation he described. What I am alerting people to is trying to >> have special-case handling for every scenario we can conceive. > > for my part, I was not trying to specify “requirements” - but identify different > scenarios that we might want to handle (better to decide how we want to do > things at the start, than to create changes later). Indeed, this is largely a discussion about what is desirable and feasible. How straightforward a particular request will be is helpful feedback. Thank you, and sorry I got snarky above. Jason ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 22:39 ` Joel Brobecker 2020-01-18 9:50 ` Iain Sandoe @ 2020-01-18 14:30 ` Joseph Myers 1 sibling, 0 replies; 30+ messages in thread From: Joseph Myers @ 2020-01-18 14:30 UTC (permalink / raw) To: Joel Brobecker Cc: Jason Merrill, Iain Sandoe, Jakub Jelinek, Richard Earnshaw (lists), gcc On Fri, 17 Jan 2020, Joel Brobecker wrote: > Also, you guys have to understand that you are all coming to me from > multiple directions at the same time, and making requests that are > not always easy to reconcile. I do completely understand that getting The issues filed on GitHub are meant to help track individual issues (both those we've fixed locally with GCC-specific patches and those, such as this one, that we haven't), although that doesn't guarantee there's a single consistent view of how best to address a particular issue. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 16:47 ` Joel Brobecker 2020-01-17 17:22 ` Iain Sandoe @ 2020-01-17 17:23 ` Joseph Myers 2020-01-17 21:14 ` Joel Brobecker 1 sibling, 1 reply; 30+ messages in thread From: Joseph Myers @ 2020-01-17 17:23 UTC (permalink / raw) To: Joel Brobecker; +Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc On Fri, 17 Jan 2020, Joel Brobecker wrote: > Would it be sufficient to say that some branches would only > trigger a summary email, but not individual commit emails? Maybe that will end up being appropriate for users / vendors branches, if we can't effectively distinguish rebased commits from new ones. But for shared fast-forward-only development branches, I think the individual commit emails are appropriate for commits new to the branch, while a summary email is appropriate for merges to the branch. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gcc-cvs mails for personal/vendor branches for merge commits 2020-01-17 17:23 ` Joseph Myers @ 2020-01-17 21:14 ` Joel Brobecker 0 siblings, 0 replies; 30+ messages in thread From: Joel Brobecker @ 2020-01-17 21:14 UTC (permalink / raw) To: Joseph Myers; +Cc: Jakub Jelinek, Richard Earnshaw (lists), gcc > > Would it be sufficient to say that some branches would only > > trigger a summary email, but not individual commit emails? > > Maybe that will end up being appropriate for users / vendors branches, if > we can't effectively distinguish rebased commits from new ones. But for > shared fast-forward-only development branches, I think the individual > commit emails are appropriate for commits new to the branch, while a > summary email is appropriate for merges to the branch. OK. I will see if there is a reasonable way to provide this. -- Joel ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2020-01-20 14:13 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-15 15:07 gcc-cvs mails for personal/vendor branches for merge commits Jakub Jelinek 2020-01-15 15:42 ` Joseph Myers 2020-01-15 15:51 ` Jakub Jelinek 2020-01-15 16:01 ` Joseph Myers 2020-01-15 16:42 ` Jason Merrill 2020-01-15 16:58 ` Joseph Myers 2020-01-15 17:09 ` Jason Merrill 2020-01-15 17:57 ` Iain Sandoe 2020-01-15 20:20 ` Jason Merrill 2020-01-19 14:10 ` Segher Boessenkool 2020-01-19 22:40 ` Julien "_FrnchFrgg_" Rivaud 2020-01-20 18:42 ` Segher Boessenkool 2020-01-15 19:21 ` Richard Earnshaw (lists) 2020-01-16 9:55 ` Joseph Myers 2020-01-16 14:28 ` Joel Brobecker 2020-01-16 14:35 ` Jakub Jelinek 2020-01-16 14:43 ` Richard Earnshaw (lists) 2020-01-16 18:51 ` Jakub Jelinek 2020-01-16 22:03 ` Joseph Myers 2020-01-16 18:58 ` Joseph Myers 2020-01-17 16:47 ` Joel Brobecker 2020-01-17 17:22 ` Iain Sandoe 2020-01-17 17:59 ` Joel Brobecker 2020-01-17 19:15 ` Jason Merrill 2020-01-17 22:39 ` Joel Brobecker 2020-01-18 9:50 ` Iain Sandoe 2020-01-18 11:07 ` Jason Merrill 2020-01-18 14:30 ` Joseph Myers 2020-01-17 17:23 ` Joseph Myers 2020-01-17 21:14 ` Joel Brobecker
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 read-only IMAP folder(s) and NNTP newsgroup(s).