Florian Weimer
>
> * c-opts.cc (c_common_post_options): █
>
> Is there something like this that works with commit messages and
> produces output compatible with GCC's expectations?
>
I use exactly this. But I modify it to write the ChangeLog to file
ChangeLog.mine ins
06 Florian Weimer
>
> * c-opts.cc (c_common_post_options): █
>
> Is there something like this that works with commit messages and
> produces output compatible with GCC's expectations?
Yes contrib/git-commit-mklog.py .
Which can also be used directly with git if you run
`c
-11-06 Florian Weimer
>
> * c-opts.cc (c_common_post_options): █
>
> Is there something like this that works with commit messages and
> produces output compatible with GCC's expectations?
contrib/mklog.py ?
Jakub
that works with commit messages and
produces output compatible with GCC's expectations?
Thanks,
Florian
Ruchit Raushan via Gcc writes:
> I don't want to receive further emails.
Please see https://gcc.gnu.org/mailman/listinfo/gcc
--
Arsen Arsenović
signature.asc
Description: PGP signature
I don't want to receive further emails.
Hello everyone.
I'll work on improving diagnostic messages for GCC's Rust front-end in Google
Summer of Code. Here is the proposal:
https://docs.google.com/document/d/1ZPRKu-PKPdZVOAZyYRq7YfSfA0eo7wyX3IL9KJoULnA/edit?usp=sharing
Feel free to leave any comments or suggestions here.
Ruihan Li
On 12/30/20 3:49 PM, Jakub Jelinek via Gcc wrote:
On Tue, Dec 29, 2020 at 12:54:53AM +0100, Gerald Pfeifer wrote:
Having spent a bit more time with GCC sources (as opposed to wwwdocs)
recently and looking for prior art to guide me, I noticed there's a
lot of options to specific the ChangeLog fil
On 12/29/20 1:49 AM, Jonathan Wakely via Gcc wrote:
On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer, wrote:
Having spent a bit more time with GCC sources (as opposed to wwwdocs)
recently and looking for prior art to guide me, I noticed there's a
lot of options to specific the ChangeLog file(s) to us
On Tue, Dec 29, 2020 at 12:54:53AM +0100, Gerald Pfeifer wrote:
> Having spent a bit more time with GCC sources (as opposed to wwwdocs)
> recently and looking for prior art to guide me, I noticed there's a
> lot of options to specific the ChangeLog file(s) to use.
>
> And correspondingly a lot o
ent, which is easier on newbies
> > and reading logs (or automatically processing them later on).
>
> I have done 5 for many years. The colon isn't a great choice imo, the
> changelog messages themselves contain colons as well, and it is nice to
> have this visually distinct. &q
?
>
> Personally I'd suggest 3 (the shortest) or 5 (the directory), but whatever
> ... as long as things become more consistent, which is easier on newbies
> and reading logs (or automatically processing them later on).
I have done 5 for many years. The colon isn't a great c
On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer, wrote:
> Having spent a bit more time with GCC sources (as opposed to wwwdocs)
> recently and looking for prior art to guide me, I noticed there's a
> lot of options to specific the ChangeLog file(s) to use.
>
> And correspondingly a lot of inconsistency
Having spent a bit more time with GCC sources (as opposed to wwwdocs)
recently and looking for prior art to guide me, I noticed there's a
lot of options to specific the ChangeLog file(s) to use.
And correspondingly a lot of inconsistency.
Right now we seem to allow for
1. gcc/cp/ChangeLog
2.
New Configuration available!
-
*New mail configuration on 11/23/2020 8:31:37 a.m.
-
1new alert
*New mail recorded on {date}
a new configuration is available for gcc@g
gcc.gnu.org Messages Summary.
(
https://view.engage.windows.com/?qs=503e51241776053d03f746128b4fa9732288d4a21e66f6cc99264378f4f31a2753a4969cb028f554fb47a65a535984bcf63f2deeb3910464c88b9a6a27f3fab82aac86a6c459c986de1189507a3f463a
)
(
https://click.engage.windows.com/?qs
On Tue, Jun 30, 2020 at 10:45:27AM +0200, Martin Liška wrote:
> Hello.
>
> After a brief discussion with Jakub, I was convinced to support 'git revert'
> where
> a ChangeLog is created from the commit the was reverted.
Ok.
Jakub
Hello.
After a brief discussion with Jakub, I was convinced to support 'git revert'
where
a ChangeLog is created from the commit the was reverted.
One example:
$ git gcc-verify 2635f9e5086318f4560997d9741fdda496b9c801 -p
Checking 2635f9e5086318f4560997d9741fdda496b9c801: OK
-- libstdc++-v3
o a document, etc. that would be helpful in
>understanding what the messages output from the compiler mean? Most
>are
>not obvious.
There is no documentation besides the source unfortunately...
Richard.
>Thanks.
>
>Roger
I was glad to see that compiler flags such as -fopt-info-vec-missed ...
provide information about what is happening under the hood w.r.t code that
can and can't be vectorized.
Can anyone point me to a document, etc. that would be helpful in
understanding what the messages output from the com
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
ached 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
alysed. There are 531 remaining.
> >
> > With the current version of the script (including the various whitelisted
> > component pairs discussed) and with data freshly downloaded from Bugzilla
> > (but with GCC commit messages from a couple of days ago, I'll do a fresh
>
pt (including the various whitelisted
> component pairs discussed) and with data freshly downloaded from Bugzilla
> (but with GCC commit messages from a couple of days ago, I'll do a fresh
> conversion run shortly), I now get a list of 481, attached.
Should "libcpp" be a com
downloaded from Bugzilla
(but with GCC commit messages from a couple of days ago, I'll do a fresh
conversion run shortly), I now get a list of 481, attached.
--
Joseph S. Myers
jos...@codesourcery.comre PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN
r7
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
number and the fixup information).
> >
> > Thanks.
> >
> > I'm afraid it was too mind-numbing to just work through the list from
> > bottom to top. Jakub and I found some problems and some that can be
> > whitelisted. I submitted another merge request.
>
&g
op. Jakub and I found some problems and some that can be
> whitelisted. I submitted another merge request.
Thanks, merged.
If people have done updates to components in Bugzilla and want a fresh
list generated using fresh Bugzilla data and the updates to component
aliases, I can readily do that (using the file of commit messages left
behind from my last conversion run), load on sourceware permitting.
--
Joseph S. Myers
jos...@codesourcery.com
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
>
tree-vect-loop.c:4252
>>>>>>> PR c++/92015: internal compiler error: in
>>>>>>> cxx_eval_array_reference, at
>>>>> cp/constexpr.c:2568
>>>>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>>>>
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
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 c
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
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 messag
"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 +
ormal commit flow these days is to use -b, because that only
removes "[PATCH...]" annotations.
Nevertheless, we will most likely keep any existing "[...]" tags.
>> We could extend the script to rewrite all [tag] attributions in tag:
>> form, but I'm not really sur
deleted.
>
> Well, true if you use "git am" without the -k or -b options; false
> otherwise. We have plenty of existing patches in the repo that have
> tags like this, though it doesn't appear to be the 'git way' I grant you.
Yes, "the normal commit flow
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.
commit
summaries. The PR92173 one actually has identical commit messages
btw,
huh. Ah, the second one (r277288) has the wrong changelog, but in the
actual changelog file as well, not something any tool could fix up (or
have we reached the singularity?)
Identical commits are normally from where the
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
g a bit more elegant than the ugly git-svn footers would be nice.
>
> Whatever reposurgeon's "write --legacy" yield seems appropriate for making
> the SVN revision ids readily available in the commit messages. I don't
> think the summary line is a good place for tha
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
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 th
od if whatever convention we do for commit messages and
> >their first line would be machine parseable as well.
>
> I think that would be pretty pointless. We're not going to have machine
> parsable summaries going forwards, so why would it really help for
> historical co
#x27; is aliased to '!f(){ git srev ${1#r} | awk -F '|'
'/^r[[:digit:]]/ {if (length($2)) print $2}' | xargs --no-run-if-empty
git show ; }; f'
These won't work once we move to Git though.
It would be good if whatever convention we do for commit messages and
t
> 'sshow' is aliased to '!f(){ git srev ${1#r} | awk -F '|'
> '/^r[[:digit:]]/ {if (length($2)) print $2}' | xargs --no-run-if-empty
> git show ; }; f'
>
> These won't work once we move to Git though.
It would be good if whatever convention we do for commit messages and
their first line would be machine parseable as well.
Segher
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
>
>> 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 --legacy" yield seems appropriate for making
> > the SVN revision id
y git-svn footers would be nice.
Whatever reposurgeon's "write --legacy" yield seems appropriate for making
the SVN revision ids readily available in the commit messages. I don't
think the summary line is a good place for that information.
I do think "Related to PR N
ice.
Whatever reposurgeon's "write --legacy" yield seems appropriate for making
the SVN revision ids readily available in the commit messages. I don't
think the summary line is a good place for that information.
I do think "Related to PR N (description)" or similar
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
1 - 100 of 331 matches
Mail list logo
