On Fri, May 01, 2020 at 09:51:53AM -0600, Jeff Law wrote:
> On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote:
> > > > > > > "Segher" == Segher Boessenkool <seg...@kernel.crashing.org> 
> > > > > > > writes:
> > 
> > Segher> My point was that this should *never* be part of patches, already.
> > 
> > FWIW, I use a few scripts so that I can keep ChangeLogs as files.
> > That's what I do when working on gdb.
> > 
> > https://github.com/tromey/git-gnu-changelog
> > 
> > This is easier on the whole, IME, because it means there is no extra
> > manual step before pushing.
> Right.  And that's really my goal here -- eliminate the manual steps.  
> Ideally I
> want to be able to git am; git push on a good patch.  Manual steps for good
> patches need to be excised from the workflow.  The ChangeLog file is a major
> problem in that regard.

I still almost always write the changelog not before sending a patch
series to the mailing list.  This is good *anyway*, it isn't a bad idea
to look at your creation from a high level first, then; and it is also
not a bad idea to look at the details, to see if you missed something.
A "self-review", if you want.

This of course also completely side-steps the issues with keeping the
changelog up-to-date that so many people struggle with (that probably
is what made me start doing this, heh).  (I also have the changelogs
in files of course, that way: the email series I send out I keep as
files).

> > Of course, better would be to remove ChangeLogs entirely (including not
> > putting anything like them into a commit message), because they are
> > largely not useful and are just make-work.  Again IMNSHO -- I know there
> > are some folks who read them, but I basically never have since switching
> > to git.
> I read them less and less.  At this point I think I read them to see if a
> particular patch in my queue has already been applied.  Otherwise I'm using 
> the
> git info.

It helps reviewing tremendously.

Having very good patch factoring would help; having very good commit
messages would help.  Together they are much better than a changelog is.
Without either (i.e., *the current status quo*), there is real value
lost.

And making it easier to shove in garbage is not an advantage :-/


Segher

Reply via email to