On Mon, Dec 02, 2019 at 08:37:14PM +, Joseph Myers wrote:
> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> > Thanks for the list. As far as I can see all of those are no longer
> > useful, so they could be jut deleted from the SVN repo (if everyone
> > else agrees!) It is much safer to delet
On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:
> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
>
> > Sure; I'm just saying rewriting old commit messages in such a style that
> > they keep standing out from new ones is a bit of a weird choice.
>
> I'd say the rewrites make them stan
I've previously noted that when we move to git, while we should use a
clean conversion with proper author attributions, we should also keep the
commits from the existing git mirror available somewhere as there are
various git-only branches there and lots of references to git commit ids
in the l
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
> > On Fri, 29 Nov 2019, Segher Boessenkool wrote:
> > > Please post the full names of all the tags you want to delete?
> >
> > Here is a list of 645 tags proposed for removal, in the var
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> Sure; I'm just saying rewriting old commit messages in such a style that
> they keep standing out from new ones is a bit of a weird choice.
I'd say the rewrites make them stand out *less* (if people avoid having
new commit messages whose summary li
"Richard Earnshaw (lists)" writes:
> The real question at this point is whether or not these commit summaries
> are better than the existing ones. Personally, I think they are (or I
> wouldn't have spent the time working on this), but I'm not the only
> person with an interest here...
+1 for hav
Segher Boessenkool :
> Do we postpone the transition another few months because we have to check
> all commits for mistakes the conversion tool made because it tried to be
> "smart"?
>
> Or will we rush in these changes, unnecessary errors and all, because
> people have invested time in doing this
On 02/12/2019 18:00, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 05:47:08PM +, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 17:25, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
On 02/12/2019 15:35, Segher Boessenkool wro
On Mon, Dec 02, 2019 at 05:47:08PM +, Richard Earnshaw (lists) wrote:
> On 02/12/2019 17:25, Segher Boessenkool wrote:
> > On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
> >> On 02/12/2019 15:35, Segher Boessenkool wrote:
> >>> On Mon, Dec 02, 2019 at 10:54:17AM +
On 02/12/2019 17:25, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 15:35, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
- author attributions are sometimes incor
On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
> On Fri, 29 Nov 2019, Segher Boessenkool wrote:
> > Please post the full names of all the tags you want to delete?
>
> Here is a list of 645 tags proposed for removal, in the various
> categories I gave. Vendor tags are only included
On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
> On 02/12/2019 15:35, Segher Boessenkool wrote:
> > On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
> >> - author attributions are sometimes incorrect - reported
> >
> > This would disqualify tha
On 02/12/2019 15:35, Segher Boessenkool wrote:
> Hi,
>
> On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
>> - author attributions are sometimes incorrect - reported
>
> This would disqualify that "conversion", for me at least. Keeping all
> warts we had in SVN is bett
Hi,
On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
> - author attributions are sometimes incorrect - reported
This would disqualify that "conversion", for me at least. Keeping all
warts we had in SVN is better than adding new lies, lies about important
matters even.
libstdc++ recently made an appearance in a glibc bug, which made me
realize that they aren't marked as NODELETE (on GNU ELF platforms).
(The bug in question was purely glibc, though.)
Are these shared objects really expected to be unloaded? Given that
libstdc++ contains many destructors, I expect
On 19/11/2019 14:56, Jason Merrill wrote:
On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
richard.earns...@arm.com> wrote:
On 18/11/2019 20:53, Jason Merrill wrote:
On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
On Mon, Nov 18, 2019 at 07:2
16 matches
Mail list logo
