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