On Sat, 2019-12-28 at 03:53 -0500, Eric S. Raymond wrote:
> In moving the history of a project old enough to have used
> more than one version-control system, I think it's good practice
> to mark the strata. I'm even interested in pinning down the
> RCS-to-CVS cutover, if there's enough evidence
Le 28/12/2019 à 21:28, Segher Boessenkool a écrit :
On Sat, Dec 28, 2019 at 05:11:47PM +, Richard Earnshaw (lists) wrote >> I
disagree. The review comments will show up as additional commits on
the branch and can be tracked back to such events. Once history gets
flattened into a major sin
On 27/12/2019 19:47, Richard Earnshaw (lists) wrote:
> Email addresses from the ChangeLog files are not validated during
> commits, so a number of typos exist in the extracted data. I've
> extracted the 'Author:' entry from a prototype conversion and then piped
> that through sort and uniq -c. Su
On 28/12/2019 20:11, Segher Boessenkool wrote:
> On Sat, Dec 28, 2019 at 04:34:20PM +, Richard Earnshaw (lists) wrote:
>> On 28/12/2019 14:54, Segher Boessenkool wrote:
>>> On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
On Sat, 28 Dec 2019, Segher Boessenkool wrote:
>>>
Snapshot gcc-9-20191228 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20191228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9
On 12/23/19 12:30 PM, Erick Ochoa wrote:
Hi,
I am working on an LTO pass which drops unused fields on structs. On my
tests, I found that the gimple generated for `sizeof` is a constant. For
example, for the following C code:
```
you also need to pay attention to offsetof.
nathan
--
Nathan Si
On Sat, Dec 28, 2019 at 05:11:47PM +, Richard Earnshaw (lists) wrote:
> On 28/12/2019 12:19, Segher Boessenkool wrote:
> > Branch merges do not mesh well with our commit policies, fwiw:
> > everything should normally be posted for public review on the mailing
> > lists. This does not really wo
On Sat, Dec 28, 2019 at 04:34:20PM +, Richard Earnshaw (lists) wrote:
> On 28/12/2019 14:54, Segher Boessenkool wrote:
> > On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
> >> On Sat, 28 Dec 2019, Segher Boessenkool wrote:
> >>
> >>> On Fri, Dec 27, 2019 at 07:47:02PM +, Richa
‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 3:39 AM, Richard Biener
wrote:
> > I'm modifying the code trying to get complex double accepted as a valid
> > type by the vectorizer.
> > This is the first time I'm dealing with GCC source so I ask for some
> > patience.
> > Functio
Joseph Myers :
> Concretely, what I'd suggest is: convert ISO-8859-1 entries in the
> checked-in list to UTF-8, removing anything that thereby becomes a
> duplicate or unnecessary; handle anything whose encoding isn't simply
> ISO-8859-1 or UTF-8 via a hardcoded entry in bugdb.py using hex escap
On Sat, 28 Dec 2019, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > I've added the list of emails that I posted yesterday to the conversion
> > scripts. I've not written anything to reprocess that yet. I want to
> > leave that until we've completed the general
On Dez 28 2019, Richard Earnshaw (lists) wrote:
> I don't know whether tools that analyse git repos to generate statistics
> about users contributions care about canonicalization of names; they may
> just key off email addresses.
git shortlog supports that via .mailmap.
Andreas.
--
Andreas Sch
On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
> I've added the list of emails that I posted yesterday to the conversion
> scripts. I've not written anything to reprocess that yet. I want to
> leave that until we've completed the general review of the preferred
> changes we want. Auto-gen
On 28/12/2019 17:14, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
>
>> My suggestion would be that we try to canonicalize all the author
>> entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that
>> would probably need further fixups to detect the addi
On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
> My suggestion would be that we try to canonicalize all the author
> entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that
> would probably need further fixups to detect the additional names that
> need rewriting.
What I've i
On 28/12/2019 12:19, Segher Boessenkool wrote:
> Branch merges do not mesh well with our commit policies, fwiw:
> everything should normally be posted for public review on the mailing
> lists. This does not really work for commits that have been set in
> stone months before.
>
I disagree. The r
On 28/12/2019 12:04, Jakub Jelinek wrote:
> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
>> Email addresses from the ChangeLog files are not validated during
>> commits, so a number of typos exist in the extracted data. I've
>> extracted the 'Author:' entry from a prot
On Sat, 28 Dec 2019, Segher Boessenkool wrote:
> > This is about extracting attributions from changelogs when unambiguous
> > there, and then correcting mistakes or otherwise making minor variants
> > more uniform.
>
> Yes, and I'm saying you probably shouldn't do that.
Extracting attributions
On 28/12/2019 14:54, Segher Boessenkool wrote:
> On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
>> On Sat, 28 Dec 2019, Segher Boessenkool wrote:
>>
>>> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
1 Author: Segher Boessenkool
*730 Au
On Sun, 22 Dec 2019, Joseph Myers wrote:
> Two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5b.git
Two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurge
On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Segher Boessenkool wrote:
>
> > On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> > > 1 Author: Segher Boessenkool
> > > *730 Author: Segher Boessenkool
> > > 2 Author:
On Sat, 28 Dec 2019, Segher Boessenkool wrote:
> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> > 1 Author: Segher Boessenkool
> > *730 Author: Segher Boessenkool
> > 2 Author: Segher Boesssenkool
>
> The first and third are only in changelogs. The
On Fri, Dec 27, 2019 at 11:35:21AM +, Joseph Myers wrote:
> On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > I'm not really sure I understand why we don't want merge commits into
> > trunk, especially for large changes. Performing archaeology on a change
> > is just so much easier i
On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> Email addresses from the ChangeLog files are not validated during
> commits, so a number of typos exist in the extracted data. I've
> extracted the 'Author:' entry from a prototype conversion and then piped
> that through
On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> 1 Author: Segher Boessenkool
> *730 Author: Segher Boessenkool
> 2 Author: Segher Boesssenkool
The first and third are only in changelogs. The second even happened
only once, afaics?
These errors only
On Fri, 27 Dec 2019, Eric S. Raymond wrote:
> > Merge info is not one of those cases.
>
> Sometimes. Some Subversion mergeinfo operations map to Git's
> branch-centric merging. Many do not, corresponding to cherry-picks
> that cannot be expressed in a Git history.
And in the case of merge commi
In moving the history of a project old enough to have used
more than one version-control system, I think it's good practice
to mark the strata. I'm even interested in pinning down the
RCS-to-CVS cutover, if there's enough evidence to establish that.
I've added an issue to the tracker about this:
27 matches
Mail list logo
