On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote:
> >
> > On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've sent another pull request fixing another 20. Here is the list
> > > with those 20 removed (and this still includes the libcpp vs
> > >
On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > I've sent another pull request fixing another 20. Here is the list
> > with those 20 removed (and this still includes the libcpp vs
> > preprocessor ones that will be handled by the new alias).
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> I've sent another pull request fixing another 20. Here is the list
> with those 20 removed (and this still includes the libcpp vs
> preprocessor ones that will be handled by the new alias).
Thanks, merged.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 20 Dec 2019 at 21:41, Joseph Myers wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
> > >
> > > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> > >
> > > > I've attached an updated list to this mail, which removes the items
> > >
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've attached an updated list to this mail, which removes the items
> > > we've analysed. There are 531 remaining.
> >
> > With the current
On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > I've attached an updated list to this mail, which removes the items
> > we've analysed. There are 531 remaining.
>
> With the current version of the script (including the various whitelisted
> c
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> I've attached an updated list to this mail, which removes the items
> we've analysed. There are 531 remaining.
With the current version of the script (including the various whitelisted
component pairs discussed) and with data freshly downloaded from
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> Jakub and I came up with the following list of suggestions for
> component changes:
Since we don't normally review changes to individual bugs, if you think
the new component is better than the old one (is a better representation
of the subject area
On Thu, 19 Dec 2019 at 16:33, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
> > >
> > > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> > >
> > > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > (most of?) the most egregious ones, like fortran fix
On Thu, 19 Dec 2019 at 16:26, Jonathan Wakely wrote:
>
> On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > (most of?) the most egregious ones, like
On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > > numbers and vice versa. Jakub and I
On 19/12/2019 16:00, Joseph Myers wrote:
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
It might be reasonable to assume rtl-optimization and
tree-optimization are aliases, and not treat it as suspicious if those
two appear mixed up. And anything where bugzilla has component debug
or lto and the c
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> It might be reasonable to assume rtl-optimization and
> tree-optimization are aliases, and not treat it as suspicious if those
> two appear mixed up. And anything where bugzilla has component debug
> or lto and the commit is tree-optimization is probab
On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > numbers and vice versa. Jakub and I have several whitelist commits
> > too, but I think they're al
On 19/12/2019 15:44, Jonathan Wakely wrote:
These scraped "INVALID" as the component from the changelog, because
it said "libgfortran/24685":
revert: re PR libfortran/24685 (real(16) formatted input is broken for
huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
r142840])
reve
On Thu, 19 Dec 2019 at 15:47, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > These scraped "INVALID" as the component from the changelog, because
> > it said "libgfortran/24685":
>
> "INVALID" means the PR was closed as INVALID rather than FIXED, which
> makes it suspect
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> These scraped "INVALID" as the component from the changelog, because
> it said "libgfortran/24685":
"INVALID" means the PR was closed as INVALID rather than FIXED, which
makes it suspect for a commit to claim to be fixing it. (Though since
those ar
These scraped "INVALID" as the component from the changelog, because
it said "libgfortran/24685":
revert: re PR libfortran/24685 (real(16) formatted input is broken for
huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
r142840])
revert: re PR libfortran/24685 (real(16) formatted
On 19/12/2019 15:17, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 14:29, Joseph Myers wrote:
On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
Best of all would be a pull request on
https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.
Note if doing that, it he
On Thu, 19 Dec 2019 at 14:29, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > Best of all would be a pull request on
> > https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
> > directly.
>
> Note if doing that, it helps to check "Allow commits f
On 19/12/2019 11:16, Jakub Jelinek wrote:
On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote:
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
tree-optimization SVN r277822])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
tr
On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> Best of all would be a pull request on
> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.
Note if doing that, it helps to check "Allow commits from members who can
merge to the target branch." when creating the
On Thu, 19 Dec 2019 at 12:42, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2019 12:35, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 19/12/2019 12:23, Jonathan Wakely wrote:
> >>> On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
>
On 19/12/2019 12:35, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
wrote:
On 19/12/2019 12:23, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
wrote:
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Jos
On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2019 12:23, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 19/12/2019 09:27, Jonathan Wakely wrote:
> >>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers
> >>> wrote:
On 19/12/2019 12:23, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
wrote:
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
On Wed, 18 Dec 2019, Joseph Myers wrote:
On Mon, 18 Nov 2019, Richard Earnshaw (lists) w
On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2019 09:27, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
> >>
> >> On Wed, 18 Dec 2019, Joseph Myers wrote:
> >>
> >>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >>>
> I've
On 19/12/2019 11:50, Richard Earnshaw (lists) wrote:
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Joseph Myers
wrote:
On Wed, 18 Dec 2019, Joseph Myers wrote:
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
I've attached a sample from the start of the fixe
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
On Wed, 18 Dec 2019, Joseph Myers wrote:
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
I've attached a sample from the start of the fixed list - the full list is far
too big to post to give
On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote:
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
> tree-optimization SVN r277822])
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
> tree-optimization SVN r277955])
> re PR
On Thu, 19 Dec 2019 at 09:27, Jonathan Wakely wrote:
>
> On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
> >
> > On Wed, 18 Dec 2019, Joseph Myers wrote:
> >
> > > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> > >
> > > > I've attached a sample from the start of the fixed list - the fu
On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
>
> On Wed, 18 Dec 2019, Joseph Myers wrote:
>
> > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >
> > > I've attached a sample from the start of the fixed list - the full list
> > > is far
> > > too big to post to give a flavour of how t
On Wed, 18 Dec 2019, Joseph Myers wrote:
> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>
> > I've attached a sample from the start of the fixed list - the full list is
> > far
> > too big to post to give a flavour of how the script currently works. Note
> > that annotations of the form
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> I've attached a sample from the start of the fixed list - the full list is far
> too big to post to give a flavour of how the script currently works. Note
> that annotations of the form [checkme: ] in the summary are for diagnostic
> purp
Joseph Myers :
> On Thu, 5 Dec 2019, Joseph Myers wrote:
>
> > On Thu, 5 Dec 2019, Eric S. Raymond wrote:
> >
> > > Joseph Myers :
> > > > I just tried a leading-segment load up to r14877, but it didn't
> > > > reproduce
> > > > the problems I see with r14877 in a full repository conversion - i
Joseph Myers :
> On Thu, 5 Dec 2019, Eric S. Raymond wrote:
>
> > Joseph Myers :
> > > I just tried a leading-segment load up to r14877, but it didn't reproduce
> > > the problems I see with r14877 in a full repository conversion - it seems
> > > the combination with something later in the histo
On Thu, 5 Dec 2019, Joseph Myers wrote:
> On Thu, 5 Dec 2019, Eric S. Raymond wrote:
>
> > Joseph Myers :
> > > I just tried a leading-segment load up to r14877, but it didn't reproduce
> > > the problems I see with r14877 in a full repository conversion - it seems
> > > the combination with so
On Thu, 5 Dec 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > I just tried a leading-segment load up to r14877, but it didn't reproduce
> > the problems I see with r14877 in a full repository conversion - it seems
> > the combination with something later in the history may be necessary to
> >
Joseph Myers :
> I just tried a leading-segment load up to r14877, but it didn't reproduce
> the problems I see with r14877 in a full repository conversion - it seems
> the combination with something later in the history may be necessary to
> reproduce the issue.
Great :-(
Well, there's a bise
On Thu, 5 Dec 2019, Eric S. Raymond wrote:
> I was much more worried about the conversion before we figured out
> that most of the remaining content mismatches seem to radiate out from
> something weird that happened at r14877. That's early enough that a
> leading-segment load including it doesn'
Joseph Myers :
> I think we currently have the following reposurgeon issues open for cases
> where the present code results in incorrect tree contents and we're hoping
> the new code will fix that (or make it much easier to find and fix the
> bugs). These are the issues that are most critical f
Richard Earnshaw (lists) :
> Ok, this is one to keep an eye on. There are a number of anomalous commmits
> at present, which Eric is working on with a new approach to replaying the
> SVN data into reposurgeon. Once that is done we're hoping that this sort of
> problem will go away.
Best case is
On Thu, 5 Dec 2019, Richard Earnshaw (lists) wrote:
> Ok, this is one to keep an eye on. There are a number of anomalous commmits
> at present, which Eric is working on with a new approach to replaying the SVN
> data into reposurgeon. Once that is done we're hoping that this sort of
> problem wi
On Thu, 5 Dec 2019 at 10:41, Jonathan Wakely wrote:
>
> On Thu, 5 Dec 2019 at 10:36, Richard Earnshaw (lists)
> wrote:
> >
> > On 05/12/2019 10:32, Jonathan Wakely wrote:
> > > On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely
> > > wrote:
> > >>
> > >> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw
On Thu, 5 Dec 2019 at 10:36, Richard Earnshaw (lists)
wrote:
>
> On 05/12/2019 10:32, Jonathan Wakely wrote:
> > On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely wrote:
> >>
> >> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> >>> I've just pushed a new trial conversion:
> >>>
> >>> ht
On 05/12/2019 10:32, Jonathan Wakely wrote:
On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely wrote:
On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
I've just pushed a new trial conversion:
https://gitlab.com/rearnsha/gcc-trial2-20191130
The main differences between this and the pre
On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely wrote:
>
> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> > I've just pushed a new trial conversion:
> >
> > https://gitlab.com/rearnsha/gcc-trial2-20191130
> >
> > The main differences between this and the previous trial are:
> > - The
On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> I've just pushed a new trial conversion:
>
> https://gitlab.com/rearnsha/gcc-trial2-20191130
>
> The main differences between this and the previous trial are:
> - The author attributions should now be fixed, please let me know if you
>
On 02/12/2019 10:54, Richard Earnshaw (lists) wrote:
> 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
On 03/12/2019 09:44, Richard Earnshaw (lists) wrote:
On 03/12/2019 00:47, Segher Boessenkool wrote:
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 s
On 03/12/2019 00:47, Segher Boessenkool wrote:
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.
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
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 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.
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
On 21/11/2019 16:40, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Eric S. Raymond wrote:
>
>> Richard Earnshaw (lists) :
>> > Nope, that was from running the go version from yesterday. This one, to
>> > be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>> >
>> > This pass used to be very fast
Richard Earnshaw (lists) :
> > But then I get errors:
> >
> > *** Unknown syntax: relax
> >
>
> Change that to
>
> set relax
Oops. He's right. It used to be a command, but that changed recently
as art of a redesign of log levels and options.
--
http://www.catb.org/~esr/";>Er
Joseph Myers :
> I see the changelogs issue is fixed (I can run a conversion past that
> point on a system with 128GB memory, with mergeinfo processing being very
> slow as described by Richard). But then I get errors:
>
> *** Unknown syntax: relax
Missing "relax" command probably means your r
On 21/11/2019 16:40, Joseph Myers wrote:
On Tue, 19 Nov 2019, Eric S. Raymond wrote:
Richard Earnshaw (lists) :
Nope, that was from running the go version from yesterday. This one, to
be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
This pass used to be very fast a couple of weeks back,
On Tue, 19 Nov 2019, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
> > Nope, that was from running the go version from yesterday. This one, to
> > be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
> >
> > This pass used to be very fast a couple of weeks back, but something
> > went in
On 19/11/2019 23:44, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Segher Boessenkool wrote:
>
>> Most of the time after I type "git log" I type "/\<123456\>". We need
>> to keep a way to easily map SVN revision ids to git commits, and
>> something a bit more elegant than the ugly git-svn footers wo
On Wed, Nov 20, 2019 at 09:25:19AM -0500, Jason Merrill wrote:
> On Wed, Nov 20, 2019 at 6:27 AM Segher Boessenkool <
> seg...@kernel.crashing.org> wrote:
>
> > It would be good if whatever convention we do for commit messages and
> > their first line would be machine parseable as well.
>
> The f
On 19/11/2019 23:44, Joseph Myers wrote:
> I do think "Related to PR N (description)" or similar is a good
> summary line to insert where the present summary line is just a ChangeLog
> date/author line.
i agree.
On Wed, Nov 20, 2019 at 6:27 AM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> It would be good if whatever convention we do for commit messages and
> their first line would be machine parseable as well.
>
The first line should be useful to humans, machines can parse the whole
message.
On Wed, Nov 20, 2019 at 11:30:36AM +, Richard Earnshaw (lists) wrote:
> On 20/11/2019 11:27, Segher Boessenkool wrote:
> >On Wed, Nov 20, 2019 at 08:58:05AM +, Jonathan Wakely wrote:
> >>These won't work once we move to Git though.
> >
> >It would be good if whatever convention we do for co
On 20/11/2019 11:27, Segher Boessenkool wrote:
On Wed, Nov 20, 2019 at 08:58:05AM +, Jonathan Wakely wrote:
Most of the time after I type "git log" I type "/\<123456\>". We need
to keep a way to easily map SVN revision ids to git commits, and
As a aside, I use these aliases often with the
On Wed, Nov 20, 2019 at 08:58:05AM +, Jonathan Wakely wrote:
> > Most of the time after I type "git log" I type "/\<123456\>". We need
> > to keep a way to easily map SVN revision ids to git commits, and
>
> As a aside, I use these aliases often with the current git-svn repo:
>
> $ git help
On Tue, 19 Nov 2019 at 23:29, Segher Boessenkool
wrote:
>
> On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> > Jason Merrill :
> > > Well, I was thinking of also giving some clue of what the commit was
> > > about. One possibly cut-off line accomplishes that, a simple revision
>
On Tue, 19 Nov 2019 at 23:52, Nicholas Krause wrote:
>
>
>
> On 11/19/19 6:44 PM, Joseph Myers wrote:
> > On Tue, 19 Nov 2019, Segher Boessenkool wrote:
> >
> >> Most of the time after I type "git log" I type "/\<123456\>". We need
> >> to keep a way to easily map SVN revision ids to git commits,
On 11/19/19 6:44 PM, Joseph Myers wrote:
On Tue, 19 Nov 2019, Segher Boessenkool wrote:
Most of the time after I type "git log" I type "/\<123456\>". We need
to keep a way to easily map SVN revision ids to git commits, and
something a bit more elegant than the ugly git-svn footers would be
On Tue, 19 Nov 2019, Segher Boessenkool wrote:
> Most of the time after I type "git log" I type "/\<123456\>". We need
> to keep a way to easily map SVN revision ids to git commits, and
> something a bit more elegant than the ugly git-svn footers would be nice.
Whatever reposurgeon's "write --le
On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> Jason Merrill :
> > Well, I was thinking of also giving some clue of what the commit was
> > about. One possibly cut-off line accomplishes that, a simple revision
> > number not so much.
Sure, but it isn't easy at all to automatic
On 19/11/2019 22:14, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> Nope, that was from running the go version from yesterday. This one, to
>> be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>>
>> This pass used to be very fast a couple of weeks back, but something
>> went in recentl
Richard Earnshaw (lists) :
> Nope, that was from running the go version from yesterday. This one, to
> be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>
> This pass used to be very fast a couple of weeks back, but something
> went in recently that's caused a major slowdown.
>
> Oh, and I'v
Richard Earnshaw (lists) :
> I've been unsuccessful so far in creating a simple reproducer. However,
> r278216 on the gcc 'ranger' branch is an example of what I mean. The
> property list for this is
>
> $ svn propget svn:mergeinfo -r278216
> FILE:///home/rearnsha/tmp/gcc-mirror/branches/ranger
On 19/11/2019 19:47, Richard Earnshaw (lists) wrote:
> On 19/11/2019 19:32, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) :
>>> I was looking at the reposurgeon code last night, and I think I can see what
>>> the problem *might* be, but I haven't had time to produce a testcase.
>>>
>>> Some of
On 19/11/2019 19:32, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> I was looking at the reposurgeon code last night, and I think I can see what
>> the problem *might* be, but I haven't had time to produce a testcase.
>>
>> Some of our commits have mergeinfo that looks a bit like this:
>>
>
On 19/11/2019 11:45, Richard Earnshaw (lists) wrote:
> On 19/11/2019 11:24, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) :
>>> Well a lot of that is a property of the conversion tool. git svn does a
>>> relatively poor job of anything other than straight history (I
>>> believe it
>>> just ig
Jason Merrill :
> Well, I was thinking of also giving some clue of what the commit was
> about. One possibly cut-off line accomplishes that, a simple revision
> number not so much.
It's conventional under Git to have comments lead with a summary sentence.
I think you're going to find that the va
Richard Earnshaw (lists) :
> I was looking at the reposurgeon code last night, and I think I can see what
> the problem *might* be, but I haven't had time to produce a testcase.
>
> Some of our commits have mergeinfo that looks a bit like this:
>
> 202022-202023,202026,202028-202029,202036,202039
On Tue, Nov 19, 2019 at 11:31 AM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be
On 19/11/2019 16:31, Segher Boessenkool wrote:
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
Yep. I don't think we need to worry about getting optimal one-line
summaries for ancient commits; something reasonably unique should be plenty.
In that case, how about just "SVN rN
On Tue, 19 Nov 2019 at 16:31, Segher Boessenkool wrote:
>
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be plenty.
>
> In that case, how ab
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> Yep. I don't think we need to worry about getting optimal one-line
> summaries for ancient commits; something reasonably unique should be plenty.
In that case, how about just "SVN rNN"? And then we don't need the
footer from git
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:21:22PM +, Richard Earnsha
On 19/11/2019 11:24, Eric S. Raymond wrote:
Richard Earnshaw (lists) :
Well a lot of that is a property of the conversion tool. git svn does a
relatively poor job of anything other than straight history (I believe it
just ignores the non-linear information.
Yes, svn-git does a *terrible* job
Joseph Myers :
> I think the main thing to make sure of in the conversion regarding that
> issue is that cherry-picks do *not* turn into merge commits
I confirm that this is how it now works.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Richard Earnshaw (lists) :
> Well a lot of that is a property of the conversion tool. git svn does a
> relatively poor job of anything other than straight history (I believe it
> just ignores the non-linear information.
Yes, svn-git does a *terrible* job on anything other than linear history.
Th
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:21:22PM +, Richard Earnshaw (lists) wrote:
>>> On 18/11/2019 18:53, Segher Boessenkool wrote:
PR target/92140: clang vs gcc
On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) wrote:
> > On 18/11/2019 18:53, Segher Boessenkool wrote:
> > > PR target/92140: clang vs gcc optimizing with adc/sbb
> > > PR fortran/91926:
On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) wrote:
> On 18/11/2019 18:53, Segher Boessenkool wrote:
> > PR target/92140: clang vs gcc optimizing with adc/sbb
> > PR fortran/91926: assumed rank optional
> > PR tree-optimization/91532: [SVE] Redundant predicated store in
> > g
On 18/11/2019 18:53, Segher Boessenkool wrote:
> On Mon, Nov 18, 2019 at 05:38:14PM +, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:11, Segher Boessenkool wrote:
>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>> we should introduce. And, I think this will ha
1 - 100 of 139 matches
Mail list logo
