Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

[Richard Biener]

On Tue, Jan 21, 2020 at 8:58 PM Martin Liška  wrote:
>
> On 1/21/20 6:30 PM, Jonathan Wakely wrote:
> > Whether they make it to trunk or not doesn't really change the fact
> > that a one-word message is poor. If it's only on your local machine,
> > do what you like. The hook only complains when such a commit is
> > published on gcc.gnu.org.
>
> I would disagree here. I used 'WIP' as my commit message for a branch
> that is an experimental and potentially fixes a PR. GCC git is a central
> point for my setup, I need to push the branch in order to pull it from
> a different machine and test it there.

So just use "WIP WIP" then ...

> Moreover, as Jason said, one can have multiple commits that will be
> squashed anyway before a patch submission.
>
> Martin

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Jakub Jelinek]

On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote:
> > Doesn't this use of [] have the same problem with git am?
> 
> No, because only 'leading' [] blocks are removed - git mailinfo --help

I've used
openmp: Teach omp_code_to_statement about rest of OpenMP statements [PR93329]
as the first line of a commit log and that [PR93329] part is completely gone
from it.

Jakub

Re: git conversion in progress

[Gerald Pfeifer]

On Mon, 13 Jan 2020, Joseph Myers wrote:
> In addition, once git.html is more complete (has the list of branches 
> added, at least) we need to update the GCC home page to link to the new 
> pages in place of those for SVN, redirect the old pages to the new ones, 
> and generally update references to SVN in wwwdocs and the GCC manuals.

I have removed all references to svnwrite.html and svn.html from our
own pages, added redirects to gitwrite.html and git.html, respectively,
and after svnwrite.html a few days ago now also removed svn.html.

There's some further changes I have in the queue, but the web site side
of things should be mostly converted now, modulo

 - more Git-specifics as you had pointed out,
 - bugs/reghunt.html which Jonathan offered to look into, and 
 - simtest-howto.html which looks a little dead to me.

Gerald

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Richard Earnshaw (lists)]

On 22/01/2020 09:07, Jakub Jelinek wrote:

On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote:

Doesn't this use of [] have the same problem with git am?


No, because only 'leading' [] blocks are removed - git mailinfo --help


I've used
openmp: Teach omp_code_to_statement about rest of OpenMP statements [PR93329]
as the first line of a commit log and that [PR93329] part is completely gone
from it.

Jakub



How did you apply the patch?

R.

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Jakub Jelinek]

On Wed, Jan 22, 2020 at 09:35:31AM +, Richard Earnshaw (lists) wrote:
> On 22/01/2020 09:07, Jakub Jelinek wrote:
> > On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote:
> > > > Doesn't this use of [] have the same problem with git am?
> > > 
> > > No, because only 'leading' [] blocks are removed - git mailinfo --help
> > 
> > I've used
> > openmp: Teach omp_code_to_statement about rest of OpenMP statements 
> > [PR93329]
> > as the first line of a commit log and that [PR93329] part is completely gone
> > from it.
> 
> How did you apply the patch?

Just git commit -a and editing the log message.
But I got the [PR.] not eaten in another commit, so ignore the above for
now (although I'm very much convinced it was in there when I wrote the
commit log).

Jakub

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Richard Earnshaw (lists)]

On 21/01/2020 19:26, Segher Boessenkool wrote:

Hi!

Thanks for doing this.

On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote:

This patch proposes some new (additional) rules for email subject lines
when contributing to GCC.  The goal is to make sure that, as far as
possible, the subject for a patch will form a good summary when the
message is committed to the repository if applied with 'git am'.



+A high-quality e-mail subject line for a contribution contains the
+following elements:



+  A brief summary


You could stress that this is the one thing that really matters.  And
it's not a summary, it's much too brief for that (at most ~50 chars),
but yup it should be something that allows *a human* to identify what
this is.



Well, it should all matter, or why are we requiring it?

I'm happy to insert 'very' in front of 'brief' and to say elsewhere that 
the entire subject (less the leading [...] part, should rarely, if ever, 
go beyond 80 characters.



Everything else is just convention.


+A component tag is a short identifier that identifies the part of
+the compiler being modified.  This highlights to the relevant
+maintainers that the patch may need their attention.  Multiple
+components may be listed if necessary.  Each component tag should be
+followed by a colon.


Often people use aaa/bbb: if drilling down a bit that way helps keep the
subject short (which is the *point* of all this: keep things better
consumable for humans).


The aaa: bbb: is really for when aaa and bbb are independent parts of 
the compiler and potentially needs multiple reviewers. aaa/bbb is when 
bbb is strictly a sub-component of aaa (for example, arm/SVE: would be 
an SVE related issue in the arm backend).  I'm certainly not against 
having that.





+The brief summary encapsulates in a few words the intent of the
+change.  For example: cleanup check_field_decls.


It should start with a capital though.  "Clean up blablal".  (So no
dot to end the sentence, this isn't a sentence).  A capital helps
the reader to quickly identify what is what, separate fluff from the
core parts.



There is a balance here to be made.  I'm mindful of Gerald's concern 
that this is perhaps overly restrictive for new users already.  I 
certainly think we should have a good house style, but getting too 
prescriptive just gets in the way of attracting good contributions.



+Some large patch sets benefit from an introductory e-mail that
+provides more context for the patch series and describes how the
+patches have been broken up to provide for review.


All non-trivial series, yeah.

Maybe we should mention how v2 etc. of patch series should show what is
changed?  If there is a good standard practice for that at all :-)



Dunno.  I think that belongs primarily in the v2 0/n mail.  It's not, 
after all, something that needs to be kept once the patches are applied.


R.


Segher

Add News-feed item for git transition

[Richard Earnshaw (lists)]

We're missing a statement on the main news feed about the git transition.
diff --git a/htdocs/index.html b/htdocs/index.html
index 41bcfe18..ef85cc97 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -54,6 +54,10 @@ mission statement.
 
 News
 
+GCC source repository converted to git.
+[2020-01-13]
+See the https://gcc.gnu.org/ml/gcc/2020-01/msg00204.html";>announcement.
+
 GCC 7.5 released
 [2019-11-14]
 

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Segher Boessenkool]

On Wed, Jan 22, 2020 at 10:00:00AM +, Richard Earnshaw (lists) wrote:
> On 21/01/2020 19:26, Segher Boessenkool wrote:
> >On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote:
> >>+  A brief summary
> >
> >You could stress that this is the one thing that really matters.  And
> >it's not a summary, it's much too brief for that (at most ~50 chars),
> >but yup it should be something that allows *a human* to identify what
> >this is.
> >
> 
> Well, it should all matter, or why are we requiring it?

Yes.

> I'm happy to insert 'very' in front of 'brief' and to say elsewhere that 
> the entire subject (less the leading [...] part, should rarely, if ever, 
> go beyond 80 characters.

The usual recommendation is 50 chars.   Which is just about right with
most MUAs.

> >Everything else is just convention.
> >
> >>+A component tag is a short identifier that identifies the part of
> >>+the compiler being modified.  This highlights to the relevant
> >>+maintainers that the patch may need their attention.  Multiple
> >>+components may be listed if necessary.  Each component tag should be
> >>+followed by a colon.
> >
> >Often people use aaa/bbb: if drilling down a bit that way helps keep the
> >subject short (which is the *point* of all this: keep things better
> >consumable for humans).
> 
> The aaa: bbb: is really for when aaa and bbb are independent parts of 
> the compiler and potentially needs multiple reviewers. aaa/bbb is when 
> bbb is strictly a sub-component of aaa (for example, arm/SVE: would be 
> an SVE related issue in the arm backend).  I'm certainly not against 
> having that.

Excellent.

> >>+The brief summary encapsulates in a few words the intent of the
> >>+change.  For example: cleanup check_field_decls.
> >
> >It should start with a capital though.  "Clean up blablal".  (So no
> >dot to end the sentence, this isn't a sentence).  A capital helps
> >the reader to quickly identify what is what, separate fluff from the
> >core parts.
> 
> There is a balance here to be made.  I'm mindful of Gerald's concern 
> that this is perhaps overly restrictive for new users already.  I 
> certainly think we should have a good house style, but getting too 
> prescriptive just gets in the way of attracting good contributions.

This is just basic email etiquette :-)

But, it's very annoying when you look at badly formatted subjects, in
"git log --oneline" for example, it is very obvious there (and long
subjects are problematic there as well btw).

Wrt balance: yes, that is one reason why I do not think we should
require all the markup stuff.

> >>+Some large patch sets benefit from an introductory e-mail that
> >>+provides more context for the patch series and describes how the
> >>+patches have been broken up to provide for review.
> >
> >All non-trivial series, yeah.
> >
> >Maybe we should mention how v2 etc. of patch series should show what is
> >changed?  If there is a good standard practice for that at all :-)
> 
> Dunno.  I think that belongs primarily in the v2 0/n mail.  It's not, 
> after all, something that needs to be kept once the patches are applied.

Sure.  Ah, we could recommend that then, to make it clear in the vM 0/N
of some series which patches changed how.  My point is that it is a
waste of time to everyone if a reviewer has to drag through everything
every time; this is double true with git, it is easy to send updated
versions of patch sets often.


Segher

Re: Add News-feed item for git transition

[Gerald Pfeifer]

On Wed, 22 Jan 2020, Richard Earnshaw (lists) wrote:
> We're missing a statement on the main news feed about the git transition.

Lovely, thanks.

Gerald

PS: Lovely referring to you creating the patch, not the missing 
announcement. ;-)

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Richard Sandiford]

"Richard Earnshaw (lists)"  writes:
> On 21/01/2020 17:20, Jason Merrill wrote:
>> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
>>> On 21/01/2020 15:39, Jakub Jelinek wrote:
 On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) 
 wrote:
>> Some examples would be useful I'd say, e.g. it is unclear in what 
>> way you
>> want the PR number to be appended, shall it be
>> something: whatever words describe it PR12345
>> or
>> something: whatever words describe it (PR12345)
>> or
>> something: whatever words describe it: PR12345
>> or
>> something: whatever words describe it [PR12345]
>> or something else?
>
> Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, 
> I'm not
> too worried.  I'd be happy with [PR #], but if folk want 
> something else,
> please say so quickly...

 [PR 12345] or [PR #12345] is bad, because the bugzilla won't 
 underline it,
 it needs to be either PR12345 word, or PR component/12345 .
>>>
>>> ok, lets go with [PR] then.
>> 
>> Doesn't this use of [] have the same problem with git am?
>
> No, because only 'leading' [] blocks are removed - git mailinfo --help
>
>> 
>> My summaries are often describing the bug I'm fixing, i.e.
>> 
>> [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.
>> 
>> which is also the first line of my ChangeLog entry.  I think you are 
>> proposing
>> 
>> [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs 
>> (PR91476)
>> 
>> which can no longer be shared with the ChangeLog.
>> 
>
> I was trying to unify this with glibc.  They specify the bug number at 
> the end of the line.
>
> We can diverge if it's generally felt to be important, but details like 
> this create needless friction for folk working in both communities.

+1 for "component: Summary [PRn]" FWIW.

PR bz-component/n works well for C++.  The problem is that so many
other PRs come under tree-optimization and rtl-optimization, which
eat up a lot of subject line characters without narrowing things down
very much.  "cselib: ... [PRn]" is both shorter and more descriptive
than "PR rtl-optimization/n - ", etc.

Same idea for "PR target/n - ...": you then need to say which target
you mean in the main summary, whereas "aarch64:  [PRn]" makes
it easier to keep the main summary short.

Maybe that's just a problem with the bz classification though...

Richard

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Marek Polacek]

On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote:
> "Richard Earnshaw (lists)"  writes:
> > On 21/01/2020 17:20, Jason Merrill wrote:
> >> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
> >>> On 21/01/2020 15:39, Jakub Jelinek wrote:
>  On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) 
>  wrote:
> >> Some examples would be useful I'd say, e.g. it is unclear in what 
> >> way you
> >> want the PR number to be appended, shall it be
> >> something: whatever words describe it PR12345
> >> or
> >> something: whatever words describe it (PR12345)
> >> or
> >> something: whatever words describe it: PR12345
> >> or
> >> something: whatever words describe it [PR12345]
> >> or something else?
> >
> > Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, 
> > I'm not
> > too worried.  I'd be happy with [PR #], but if folk want 
> > something else,
> > please say so quickly...
> 
>  [PR 12345] or [PR #12345] is bad, because the bugzilla won't 
>  underline it,
>  it needs to be either PR12345 word, or PR component/12345 .
> >>>
> >>> ok, lets go with [PR] then.
> >> 
> >> Doesn't this use of [] have the same problem with git am?
> >
> > No, because only 'leading' [] blocks are removed - git mailinfo --help
> >
> >> 
> >> My summaries are often describing the bug I'm fixing, i.e.
> >> 
> >> [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.
> >> 
> >> which is also the first line of my ChangeLog entry.  I think you are 
> >> proposing
> >> 
> >> [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs 
> >> (PR91476)
> >> 
> >> which can no longer be shared with the ChangeLog.
> >> 
> >
> > I was trying to unify this with glibc.  They specify the bug number at 
> > the end of the line.
> >
> > We can diverge if it's generally felt to be important, but details like 
> > this create needless friction for folk working in both communities.
> 
> +1 for "component: Summary [PRn]" FWIW.
> 
> PR bz-component/n works well for C++.  The problem is that so many
> other PRs come under tree-optimization and rtl-optimization, which
> eat up a lot of subject line characters without narrowing things down
> very much.  "cselib: ... [PRn]" is both shorter and more descriptive
> than "PR rtl-optimization/n - ", etc.

Yeah, the cselib version definitely looks preferable to me.

What if a patch touches more than just the C++ FE, do we want "c,c++:"?
Though kernel uses

net: sched: act_ctinfo: fix memory leak
locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN

If a patch touches various spots in the optimizers, maybe we can
just go with "tree-opt:" or "rtl:"?

Further, I suppose multiple PRs fixed by a single patch would look like:

c++: Implement DR 666 [PR57, PR12345]

Marek

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Richard Earnshaw (lists)]

On 22/01/2020 16:28, Marek Polacek wrote:

On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote:

"Richard Earnshaw (lists)"  writes:

On 21/01/2020 17:20, Jason Merrill wrote:

On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:

On 21/01/2020 15:39, Jakub Jelinek wrote:

On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists)
wrote:

Some examples would be useful I'd say, e.g. it is unclear in what
way you
want the PR number to be appended, shall it be
something: whatever words describe it PR12345
or
something: whatever words describe it (PR12345)
or
something: whatever words describe it: PR12345
or
something: whatever words describe it [PR12345]
or something else?


Glibc use "[BZ #]" - obviously BZ becomes PR, but after that,
I'm not
too worried.  I'd be happy with [PR #], but if folk want
something else,
please say so quickly...


[PR 12345] or [PR #12345] is bad, because the bugzilla won't
underline it,
it needs to be either PR12345 word, or PR component/12345 .


ok, lets go with [PR] then.


Doesn't this use of [] have the same problem with git am?


No, because only 'leading' [] blocks are removed - git mailinfo --help



My summaries are often describing the bug I'm fixing, i.e.

[PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.

which is also the first line of my ChangeLog entry.  I think you are
proposing

[COMMITTED] c++: Fix anon-namespace reference temp clash between TUs
(PR91476)

which can no longer be shared with the ChangeLog.



I was trying to unify this with glibc.  They specify the bug number at
the end of the line.

We can diverge if it's generally felt to be important, but details like
this create needless friction for folk working in both communities.


+1 for "component: Summary [PRn]" FWIW.

PR bz-component/n works well for C++.  The problem is that so many
other PRs come under tree-optimization and rtl-optimization, which
eat up a lot of subject line characters without narrowing things down
very much.  "cselib: ... [PRn]" is both shorter and more descriptive
than "PR rtl-optimization/n - ", etc.


Yeah, the cselib version definitely looks preferable to me.

What if a patch touches more than just the C++ FE, do we want "c,c++:"?


c-common: or c-family:?


Though kernel uses

net: sched: act_ctinfo: fix memory leak


I'd read that as a patch that crosses the three separate components.


locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN


And this would be a patch that affectst the rwsem sub-component of locking.



If a patch touches various spots in the optimizers, maybe we can
just go with "tree-opt:" or "rtl:"?



Not sure we want to get that prescriptive.  Things are likely to change 
around anyway.  rtl: would suggest it was one of the non-specific 
rtl-related issues, tree: similarly for a tree-related issue.



Further, I suppose multiple PRs fixed by a single patch would look like:

c++: Implement DR 666 [PR57, PR12345]


Depends on the overall context.  In the subject line I think it would be 
acceptable to reference just one, perhaps two PRs.  If there are more, 
then something like

[PRnnn, ...]

would probably be an acceptable way of showing that more were referenced 
later in the body.


Marek

Re: What needs to be satisfied to become a type qualifier in standard?

[Joseph Myers]

On Wed, 22 Jan 2020, Akshat Garg wrote:

> Hello everyone,
> 
> I am trying to see how a new type qualifier only for pointer variables is
> suitable to be in standard semantically. I have this thread (
> https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02015.html ) where Joseph
> discussed a bit about what a new type qualifier should satisfy. Can
> somebody help me to know the full list of existing logic that needs to be
> satisfied for a new type qualifier.
> 
> Is going with this doc (
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf ), in section
> 6.7.3, sufficient?

No.  You should look at all the places, throughout clause 6, that refer to 
such things as "qualified or unqualified type", or to a qualified or 
unqualified version of a given type.  It's not the subclause specifically 
about qualifiers that's the concern so much as all the places involving 
qualifiers all over the rest of the standard.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: git conversion in progress

[Peter Bergner]

On 1/22/20 3:26 AM, Gerald Pfeifer wrote:
> On Mon, 13 Jan 2020, Joseph Myers wrote:
>> In addition, once git.html is more complete (has the list of branches 
>> added, at least) we need to update the GCC home page to link to the new 
>> pages in place of those for SVN, redirect the old pages to the new ones, 
>> and generally update references to SVN in wwwdocs and the GCC manuals.
> 
> I have removed all references to svnwrite.html and svn.html from our
> own pages, added redirects to gitwrite.html and git.html, respectively,
> and after svnwrite.html a few days ago now also removed svn.html.

The rsync.html page can be removed too, since that was a way to download
the entire svn repo.  With git clone, you get the entire repo, so rsync
isn't needed anymore.

Peter

[PATCH, v3] wwwdocs: e-mail subject lines for contributions

[Richard Earnshaw (lists)]

[updated based on v2 discussions]

This patch proposes some new (additional) rules for email subject lines
when contributing to GCC.  The goal is to make sure that, as far as
possible, the subject for a patch will form a good summary when the
message is committed to the repository if applied with 'git am'.  Where
possible, I've tried to align these rules with those already in
use for glibc, so that the differences are minimal and only where
necessary.

Some things that differ from existing practice (at least by some people)
are:

- Use ':' rather than '[]'
  - This is more git friendly and works with 'git am'.
- Put bug numbers at the end of the line rather than the beginning.
  - The bug number is useful, but not as useful as the brief summary.
Also, use the shortened form, as the topic part is more usefully
conveyed in the proper topic field (see above).
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index 042ff069..558bae29 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -249,13 +249,143 @@ that ChangeLog entries may be included as part of the patch and diffs
 representing new files may be omitted, especially if large, since they
 can be accessed directly from the repository.) 
 
+E-mail subject lines
+
+Your contribution e-mail subject line will become the first line of
+the commit message for your patch.
+
+A high-quality e-mail subject line for a contribution contains the
+following elements:
+
+
+  A classifier
+  Component tags
+  An optional series identifier
+  A brief summary
+  An optional bug number
+
+
+The entire line (excluding the classifier) should not exceed 75
+characters.
+
+Classifier
+
+The classifier identifies the type of contribution, for example a
+patch, an RFC (request for comments) or a committed patch (where
+approval is not necessary.  The classifier should be written in upper
+case and surrounded with square brackets.  This is the only component
+of the e-mail subject line that will not appear in the commit itself.
+The classifier may optionally contain a version number (vN) and
+a series marker (N/M).  Examples are:
+
+
+  [PATCH] - a single patch
+  [PATCH v2] - the second version of a single patch
+  [PATCH 3/7] - the third patch in a series of seven
+patches
+  [RFC] - a point of discussion, may contain a patch
+  [COMMITTED] - a patch that has already been committed.
+
+
+Component tags
+
+A component tag is a short identifier that identifies the part of
+the compiler being modified.  This highlights to the relevant
+maintainers that the patch may need their attention.  Multiple
+components may be listed if necessary.  Each component tag should be
+followed by a colon.  For example,
+
+
+  libstdc++:
+  combine:
+  vax: testsuite:
+
+
+Some large components may be subdivided into sub-components.  If
+the subcomponent name is not disctinct in its own right, you can use the
+form component/sub-component:.
+
+Series identifier
+
+The series identifier is optional and is only relevant if a number of
+patches are needed in order to effect an overall change.  It should be
+a short string that identifies the series (it is common to all
+patches) and should be followed by a single dash surrounded by white
+space.
+
+A Very Brief summary
+
+The brief summary encapsulates in a few words the intent of the
+change.  For example: cleanup check_field_decls.
+Although, very short, the summary should be distinct so that it will
+not be confused with other patches.
+
+Bug number
+
+If your patch relates a bug in the compiler for which there is an
+existing PR number the bug number should be stated.  Use the
+short-form variant [PRn] without the bugzilla
+component identifier and with no space between 'PR' and the number.
+The body of the commit message should still contain the full form
+(PR /n) within the body of
+the commit message so that Bugzilla will correctly notice the
+commit.  If your patch relates to two bugs, then write
+[PRn, PRm].  For multiple
+bugs, just cite the most relevant one in the summary and use an
+elipsis instead of the second, or subsequent PR numbers; list all the
+related PRs in the body of the commit message in the normal way.
+
+It is not necessary to cite bugs that are closed as duplicates of
+another unless there is something specific to that report that
+is not covered by the parent bug.
+
+Other messages
+
+Some large patch sets benefit from an introductory e-mail that
+provides more context for the patch series and describes how the
+patches have been broken up to provide for review.  The convention is
+that such messages should follow the same format as described above,
+but the patch number should be set to zero, for example: [PATCH
+0/7].  Remember that the introductory message will not be
+committed with the patches themselves, so it should not contain any
+important information that is not also covered in the individual
+patches.  If you send a summary e-mail with a series

Re: git conversion in progress

[Jakub Jelinek]

On Wed, Jan 22, 2020 at 11:41:22AM -0600, Peter Bergner wrote:
> On 1/22/20 3:26 AM, Gerald Pfeifer wrote:
> > On Mon, 13 Jan 2020, Joseph Myers wrote:
> >> In addition, once git.html is more complete (has the list of branches 
> >> added, at least) we need to update the GCC home page to link to the new 
> >> pages in place of those for SVN, redirect the old pages to the new ones, 
> >> and generally update references to SVN in wwwdocs and the GCC manuals.
> > 
> > I have removed all references to svnwrite.html and svn.html from our
> > own pages, added redirects to gitwrite.html and git.html, respectively,
> > and after svnwrite.html a few days ago now also removed svn.html.
> 
> The rsync.html page can be removed too, since that was a way to download
> the entire svn repo.  With git clone, you get the entire repo, so rsync
> isn't needed anymore.

I disagree, it isn't just about downloading a svn repo, but mailing list
archives too:
rsync rsync://gcc.gnu.org/ | grep gcc
crossgcc-ftpcrossgcc ftp area ()
gcc-ftp gcc ftp area ()
gcc-svn gcc svn repository ()
gcc-cvs gcc cvs repository ()
gcc-gnats   gcc gnats database ()
gcc-htdocs  gcc htdocs ()
crossgcc-ml-archive crossgcc mailing list archive ()
gcc-ml-archive  gcc mailing list archive ()
gccadmin-ml-archive gccadmin mailing list archive ()
gcc-announce-ml-archive gcc-announce mailing list archive ()
gcc-bugs-ml-archive gcc-bugs mailing list archive ()
gcc-cvs-ml-archive  gcc-cvs mailing list archive ()
gcc-cvs-wwwdocs-ml-archive  gcc-cvs-wwwdocs mailing list archive ()
gcc-help-ml-archive gcc-help mailing list archive ()
gcc-patches-ml-archive  gcc-patches mailing list archive ()
gcc-prs-ml-archive  gcc-prs mailing list archive ()
gcc-regression-ml-archive   gcc-regression mailing list archive ()
gcc-testresults-ml-archive  gcc-testresults mailing list archive ()

Jakub

Question about git: merging to gccgo branch

[Ian Lance Taylor]

I'm trying to merge trunk revision
7c46e71d016c86971ac26c6fa38d76482859f296 to the gccgo branch.  I did
this by checking out the branch ("git checkout origin/devel/gccgo")
and running "git merge master".

I'm not sure whether I should keep reporting this kind of operation to
gcc-patches now that we've switched to git, but that is not my
question.

After testing the result of "git merge master", I run "git push origin
HEAD:devel/gccgo" to push the result to gcc.gnu.org.  That fails with
this:

git push origin HEAD:devel/gccgo
Enumerating objects: 4069, done.
Counting objects: 100% (3017/3017), done.
Delta compression using up to 8 threads
Compressing objects: 100% (1517/1517), done.
Writing objects: 100% (1692/1692), 1.37 MiB | 4.58 MiB/s, done.
Total 1692 (delta 1163), reused 154 (delta 113), pack-reused 0
remote: Resolving deltas: 100% (1163/1163), completed with 979 local objects.
remote: *** This update introduces too many new commits (581), which would
remote: *** trigger as many emails, exceeding the current limit (100).
remote: *** Contact your repository adminstrator if you really meant
remote: *** to generate this many commit emails.
remote: error: hook declined to update refs/heads/devel/gccgo
To git+ssh://gcc.gnu.org/git/gcc
 ! [remote rejected] HEAD -> devel/gccgo (hook declined)
error: failed to push some refs to 'git+ssh://i...@gcc.gnu.org/git/gcc'

I don't want to send 581 e-mails.  I would be happy not sending any
e-mails at all.  I would also be happy sending 1 e-mail.

What should I do?

Thanks.

Ian

Re: Question about git: merging to gccgo branch

[Joseph Myers]

On Wed, 22 Jan 2020, Ian Lance Taylor wrote:

> I don't want to send 581 e-mails.  I would be happy not sending any
> e-mails at all.  I would also be happy sending 1 e-mail.

This is the issue we've discussed in 
 and the messages linked 
from there.

Until we have a proper fix not to send emails for the commits being 
merged, I've increased that limit to 1000 for GCC, as it doesn't seem 
useful to make people split the commits merged into batches of at most 
100.  I've also disabled the check for the default commit message for 
merge commits, since it seems that wasn't being useful in practice for 
branches where merges are appropriate and a separate check prevents merge 
commits on master and release branches.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Question about git: merging to gccgo branch

[Ian Lance Taylor]

On Wed, Jan 22, 2020 at 10:39 AM Joseph Myers  wrote:
>
> On Wed, 22 Jan 2020, Ian Lance Taylor wrote:
>
> > I don't want to send 581 e-mails.  I would be happy not sending any
> > e-mails at all.  I would also be happy sending 1 e-mail.
>
> This is the issue we've discussed in
>  and the messages linked
> from there.
>
> Until we have a proper fix not to send emails for the commits being
> merged, I've increased that limit to 1000 for GCC, as it doesn't seem
> useful to make people split the commits merged into batches of at most
> 100.  I've also disabled the check for the default commit message for
> merge commits, since it seems that wasn't being useful in practice for
> branches where merges are appropriate and a separate check prevents merge
> commits on master and release branches.

Thanks.  Should I go ahead and commit and generate 581 e-mail
messages, or should I wait?  In order to keep up with the Go release
cycle I'd like to commit this merge soon if possible.

Ian

Re: Question about git: merging to gccgo branch

[Joseph Myers]

On Wed, 22 Jan 2020, Ian Lance Taylor wrote:

> Thanks.  Should I go ahead and commit and generate 581 e-mail
> messages, or should I wait?  In order to keep up with the Go release
> cycle I'd like to commit this merge soon if possible.

I suggest going ahead and committing.

-- 
Joseph S. Myers
jos...@codesourcery.com

Ordem 1303202 inclusão em CPF

[SUZANA EUGENIO DOS SANTOS 613277 gcby]

Documento 429kb (Visualizar) 




Boa tarde,  segue em anexo Guia do 
pedido,Cadastramento da inclusão em CPF.
Atenciosamente,SUZANA EUGENIO DOS SANTOS

Re: git conversion in progress

[Gerald Pfeifer]

On Wed, 22 Jan 2020, Jakub Jelinek wrote:
>> The rsync.html page can be removed too, since that was a way to download
>> the entire svn repo.  With git clone, you get the entire repo, so rsync
>> isn't needed anymore.
> I disagree, it isn't just about downloading a svn repo, but mailing list
> archives too:

And notably our download site (for use by mirror sites):

> gcc-ftp   gcc ftp area ()

I'll take the AI to document this explicitly after my current set
of outstanding changes.

Gerald