This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v3] Re: avoid useless if-before-free tests


Janne Blomqvist wrote:

> On Mon, Apr 18, 2011 at 18:08, Jim Meyering <jim@meyering.net> wrote:
>> I've rebased and divided/reordered these changes as you suggested.
>> Here are the fortran parts. ?I'll post the other parts separately.
>> Parts 1 and 3 are manual. ?Part 2 is the big mechanical change with
>> two manual adjustments:
>>
>> ?[PATCH 1/3] gfortran: remove cpp definition of free, ...
>> ?[PATCH 2/3] convert each use of gfc_free (p) to free (p)
>> ?[PATCH 3/3] gfortran: remove now-unused definition of gfc_free
>
> Thanks. The patches themselves are ok, however the changelog parts
> should conform to the layout used otherwise for changelog entries (GNU
> ChangeLog format, IIRC).  The commit logs themselves that you have now
> used are, IMHO, more informative and contain less clutter, but alas..
>
> Note that it's recommended and usually easiest to provide changelog
> entries separately, not as diffs from the ChangeLog file.

Ok.  I interpret that as meaning I should add a line for each
file/function affected by the large mechanical change in part 2.
I will append that to the existing ChangeLog entry.
Thanks to Ralf's vc-chlog, that will be automatic:

    http://git.sv.gnu.org/cgit/vc-dwim.git/tree/README

> Then when
> you commit you insert the entry. This avoids the problem of frequent
> conflicts as the top of the changelog file changes for every commit.

If you work with the gcc repository using git, it's easy to rebase even
pesky ChangeLog diffs once you hook up Bruno Haible's git-merge-changelog:

    http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c

If you'd like me to change the other two ChangeLog entries
or any commit log message, please let me know.

> (Why we, in the age of non-sucky version control, persist in keeping
> manual changelog files is beyond me..)

I couldn't agree more ;-)
Even in projects without a VC'd ChangeLog file,
I still keep one (and build up each ChangeLog entry as usual)
and use vc-dwim to automatically cross-check any change I make.
It regularly warns me about a changed file that's listed in
ChangeLog but for which my editor has unsaved changes.

> With these changes, Ok for trunk. Thanks a lot for the contribution!

Thanks for the review.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]