On Tue, Jul 31, 2018 at 08:18:33PM -0400, Trevor Saunders wrote:
> And that's ignoring the much larger amount of busywork involved in
> generating the changelog in the first place which if you follow the GNU
> rules about describing the diff without explaining it is basically by
> definition
On Wed, Aug 01, 2018 at 12:16:57AM +0100, Maciej W. Rozycki wrote:
> On Thu, 5 Jul 2018, Tom Tromey wrote:
>
> > I use git-merge-changelog from gnulib. If you want to use git am and
> > avoid manually copying ChangeLog text from the commit message back into
> > the appropriate files, then it's
ga, forgot to attach the script in my previous message, so here it is.
thanks
Trev
On Wed, Aug 01, 2018 at 12:16:57AM +0100, Maciej W. Rozycki wrote:
> On Thu, 5 Jul 2018, Tom Tromey wrote:
>
> > I use git-merge-changelog from gnulib. If you want to use git am and
> > avoid manually copying
On Thu, 5 Jul 2018, Tom Tromey wrote:
> I use git-merge-changelog from gnulib. If you want to use git am and
> avoid manually copying ChangeLog text from the commit message back into
> the appropriate files, then it's much better to install the driver and
> include the ChangeLog diffs in the
On Mon, Jul 23, 2018 at 02:48:12PM +, Joseph Myers wrote:
> On Mon, 23 Jul 2018, Richard Biener wrote:
>
> > Does -L "work" with codebases that become more and more C++? I do realize
>
> Well, you can specify an arbitrary regular expression for your funcname
> line with -L if you need to.
On Mon, 23 Jul 2018, Richard Biener wrote:
> Does -L "work" with codebases that become more and more C++? I do realize
Well, you can specify an arbitrary regular expression for your funcname
line with -L if you need to.
--
Joseph S. Myers
jos...@codesourcery.com
On 7/23/18, Segher Boessenkool wrote:
> On Mon, Jul 23, 2018 at 04:03:31PM +0300, Alexander Monakov wrote:
>> Not necessarily in the source tree: individual users can put that into
>> their
>> $XDG_CONFIG_HOME/git/attributes or $HOME/.config/git/attributes.
>
> And then that user has *all* .md
On Mon, Jul 23, 2018 at 04:03:31PM +0300, Alexander Monakov wrote:
> Not necessarily in the source tree: individual users can put that into their
> $XDG_CONFIG_HOME/git/attributes or $HOME/.config/git/attributes.
And then that user has *all* .md files treated as GCC machine description
files.
On Mon, 23 Jul 2018, Segher Boessenkool wrote:
> For example for .md files you can use
>
> [diff "md"]
> xfuncname = "^\\(define.*$"
>
> in your local clone's .git/config
>
> and
>
> *.md diff=md
>
> in .gitattributes (somewhere in the source tree).
Not necessarily in the source
On Mon, Jul 23, 2018 at 11:52:03AM +0200, Richard Biener wrote:
> Does -L "work" with codebases that become more and more C++? I do realize
> that grepping ChangeLogs gets more difficult here as well given there are no
> clear rules how to "mangle" C++ function/entity names in ChangeLog entries.
On Fri, Jul 20, 2018 at 11:04 PM Joseph Myers wrote:
>
> On Thu, 5 Jul 2018, Aldy Hernandez wrote:
>
> > However, even if you could "git log --grep" the commit messages, I assume
> > your
> > current use is grepping for function names and such, right? Being able to
> > grep
> > a commit message
On Thu, 5 Jul 2018, Aldy Hernandez wrote:
> However, even if you could "git log --grep" the commit messages, I assume your
> current use is grepping for function names and such, right? Being able to grep
> a commit message won't solve that problem, or am I missing something?
If you know what
As far as I am concerned, the problem with ChangeLogs is one with the
format rather than one with having files called ChangeLog. (The GNU
Coding Standards have permitted automatic generation of ChangeLog at
release time from version control information since 1996.)
The main issues I see with
> On Jul 10, 2018, at 2:18 PM, NightStrike wrote:
>
> On Fri, Jul 6, 2018 at 1:17 AM, Siddhesh Poyarekar
> wrote:
>> ...
>>
>> We had discussed making addition of ChangeLog entries into the commit
>> message mandatory but the issue there is that commit logs cannot be (or more
>> precisely,
On Fri, Jul 6, 2018 at 1:17 AM, Siddhesh Poyarekar wrote:
> On 07/05/2018 05:02 PM, Richard Biener wrote:
>>
>> I assumed you just want to remove the ChangeLog files, not change
>> contents.
>> Thus I assumed the commit message would simply contain the ChangeLog
>> entry as we requie it today?
On 07/10/2018 08:19 PM, Frank Ch. Eigler wrote:
siddhesh wrote:
[...] We had discussed making addition of ChangeLog entries into the
commit message mandatory but the issue there is that commit logs
cannot be (or more precisely, should not be) modified after they're
pushed so errors in
siddhesh wrote:
> [...] We had discussed making addition of ChangeLog entries into the
> commit message mandatory but the issue there is that commit logs
> cannot be (or more precisely, should not be) modified after they're
> pushed so errors in ChangeLog entries will remain. [...]
In such a
On 07/05/2018 05:02 PM, Richard Biener wrote:
I assumed you just want to remove the ChangeLog files, not change contents.
Thus I assumed the commit message would simply contain the ChangeLog
entry as we requie it today? In that case git log --grep would still provide
everything grepping
> "Florian" == Florian Weimer writes:
Florian> To some degree, it's a bit of a chicken-and-egg problem because
Florian> “git am” tends to choke on ChangeLog patches (so we can't
Florian> really use it today)
FWIW, installing a ChangeLog merge driver fixes this.
I use git-merge-changelog
On 7/5/18, Aldy Hernandez wrote:
> After 20 years of hacking on GCC I feel like I have literally wasted
> days of my life typing out ChangeLog entries that could have easily been
> generated programmatically.
>
> Can someone refresh my memory here, what are the remaining arguments for
> requiring
* Paul Koning:
>> On Jul 5, 2018, at 10:43 AM, Florian Weimer wrote:
>>
>> * Aldy Hernandez:
>>
>>> Can someone refresh my memory here, what are the remaining arguments for
>>> requiring ChangeLog entries?
>>
>> ChangeLog entries are part of the review, commit messages are not, so
>> you end
> But this is against GNU policy for ChangeLog entries. Explanations of
> the change should go into the source code, as comments.
No, explanation of the *code* should go into the source code, as comments.
The source code is not the place for a history of the form:
"In 1999, this code did XYZ,
On 07/05/2018 02:07 AM, Richard Biener wrote:
On Thu, Jul 5, 2018 at 9:47 AM Aldy Hernandez wrote:
After 20 years of hacking on GCC I feel like I have literally wasted
days of my life typing out ChangeLog entries that could have easily been
generated programmatically.
Can someone refresh my
> On Jul 5, 2018, at 10:44 AM, Florian Weimer wrote:
>
> * Richard Kenner:
>
>>> GCC ChangeLogs don't record the purpose of the change. They say what
>>> changed,
>>> but not why.
>>
>> That depends on how you define "purpose". Let's take a random entry,
>> from a 1999 change of mine:
>>
On Jul 05 2018, Florian Weimer wrote:
> (Of course, this policy is problematic if you *remove* code.)
You can still add a comment why you are not doing something.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> On Jul 5, 2018, at 10:43 AM, Florian Weimer wrote:
>
> * Aldy Hernandez:
>
>> Can someone refresh my memory here, what are the remaining arguments for
>> requiring ChangeLog entries?
>
> ChangeLog entries are part of the review, commit messages are not, so
> you end up with surprises
* Richard Kenner:
>> GCC ChangeLogs don't record the purpose of the change. They say what changed,
>> but not why.
>
> That depends on how you define "purpose". Let's take a random entry,
> from a 1999 change of mine:
>
> * expr.c (expand_expr): If ignoring reference operations,
>
* Aldy Hernandez:
> Can someone refresh my memory here, what are the remaining arguments for
> requiring ChangeLog entries?
ChangeLog entries are part of the review, commit messages are not, so
you end up with surprises there. At least that's what happens in
glibc.
> GCC ChangeLogs don't record the purpose of the change. They say what changed,
> but not why.
That depends on how you define "purpose". Let's take a random entry,
from a 1999 change of mine:
* expr.c (expand_expr): If ignoring reference operations,
just expand the operands.
On Thu, 5 Jul 2018, Richard Kenner wrote:
> > After 20 years of hacking on GCC I feel like I have literally wasted
> > days of my life typing out ChangeLog entries that could have easily been
> > generated programmatically.
> >
> > Can someone refresh my memory here, what are the remaining
On Thu, Jul 5, 2018 at 7:53 AM, Richard Biener
wrote:
> On Thu, Jul 5, 2018 at 1:48 PM NightStrike wrote:
>>
>> On Thu, Jul 5, 2018 at 6:28 AM, Richard Biener
>> wrote:
>> > On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou
>> > wrote:
>> >>
>> >> > They are definitely useful in my day-to-day
On Thu, Jul 05, 2018 at 01:01:45PM +0200, Jakub Jelinek wrote:
> We have contrib/mklog that can do something semi-automatically, I guess any
> improvements there are welcome.
> It works on patches and thus is limited to the info that the patch (usually
> with diff -p) provides, I guess if it could
On Thu, Jul 5, 2018 at 1:48 PM NightStrike wrote:
>
> On Thu, Jul 5, 2018 at 6:28 AM, Richard Biener
> wrote:
> > On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou wrote:
> >>
> >> > They are definitely useful in my day-to-day work when tracking down
> >> > changes
> >> > given I can easily grep
On Thu, Jul 5, 2018 at 6:28 AM, Richard Biener
wrote:
> On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou wrote:
>>
>> > They are definitely useful in my day-to-day work when tracking down changes
>> > given I can easily grep them.
>>
>> Seconded.
>>
>> > I think that any change here should be
On Thu, Jul 5, 2018 at 1:01 PM Jakub Jelinek wrote:
>
> On Thu, Jul 05, 2018 at 06:46:11AM -0400, Aldy Hernandez wrote:
> > However, even if you could "git log --grep" the commit messages, I assume
> > your current use is grepping for function names and such, right? Being able
> > to grep a
> After 20 years of hacking on GCC I feel like I have literally wasted
> days of my life typing out ChangeLog entries that could have easily been
> generated programmatically.
>
> Can someone refresh my memory here, what are the remaining arguments for
> requiring ChangeLog entries?
I take
On Thu, Jul 05, 2018 at 06:46:11AM -0400, Aldy Hernandez wrote:
> However, even if you could "git log --grep" the commit messages, I assume
> your current use is grepping for function names and such, right? Being able
> to grep a commit message won't solve that problem, or am I missing
>
On 07/05/2018 04:07 AM, Richard Biener wrote:
On Thu, Jul 5, 2018 at 9:47 AM Aldy Hernandez wrote:
After 20 years of hacking on GCC I feel like I have literally wasted
days of my life typing out ChangeLog entries that could have easily been
generated programmatically.
Can someone refresh
On Thu, 5 Jul 2018 at 11:28, Richard Biener wrote:
>
> On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou wrote:
> >
> > > They are definitely useful in my day-to-day work when tracking down
> > > changes
> > > given I can easily grep them.
> >
> > Seconded.
> >
> > > I think that any change here
On Jul 05 2018, Richard Biener wrote:
> I was told there's git grep which may be used to grep commit logs?
To grep commit logs you use git log --grep. git grep searches content.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4
On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou wrote:
>
> > They are definitely useful in my day-to-day work when tracking down changes
> > given I can easily grep them.
>
> Seconded.
>
> > I think that any change here should be _after_ we've switched to git
> > (finally).
>
> Well, git doesn't
> They are definitely useful in my day-to-day work when tracking down changes
> given I can easily grep them.
Seconded.
> I think that any change here should be _after_ we've switched to git
> (finally).
Well, git doesn't make anything easier than subversion in this area so...
--
Eric
On Thu, Jul 5, 2018 at 9:47 AM Aldy Hernandez wrote:
>
> After 20 years of hacking on GCC I feel like I have literally wasted
> days of my life typing out ChangeLog entries that could have easily been
> generated programmatically.
>
> Can someone refresh my memory here, what are the remaining
43 matches
Mail list logo
