Re: Not usable email content encoding
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 > > > > > > > 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
Re: Not usable email content encoding
On Fri, May 01, 2020 at 10:37:48PM +0200, Martin Jambor wrote: > On Fri, May 01 2020, Jeff Law wrote: > >> I also find writing them useful as it forces me to go through every > >> patch one last time before submitting it :-) If you spend some time > >> configuring your text editor and git, the boilerplate stuff can be > >> generated automatically. > > Agreed on all the points above. I can't count how many patches I've > > written through the years, then got to the ChangeLog step and realized > > that further work was needed. > > I can relate to that :-) How hard it is to write the changelog for a patch is a very good canary for if the patch should be split into a few pieces. For example, unrelated changes (whitespace for example) should never be part of the same patch. Unrelated cleanups, or restructurings to make it easier to fit in the new changes, belong to a preparatory patch (or very sometimes one at the end of the series -- which is sometimes easier to do as well, even if it is not the best idea). If a patch does ten gazillion the same changes, it helps to have that as a separate patch. Bisectability problems (the tree should work after every commit) are usually easily solved with some strategically placed (temporary) "if", or the like. > >> I do not think this can be provided in any other way that would not > >> resemble a ChangeLog. I do support the effort to put them into commit > >> messages only though (and then perhaps generate the files from that). > > That's where I lean as well. I could also live with the ChangeLog being > > generated by a commit hook > > Please note that this would change the commit hash from what the author > had on their computer, which would be a bit unfortunate. But generating > them along with the "Daily bump" seems like a nice alternative. Yeah, the latter is much nicer, eventually at least. Segher
בשורות טובות לעסקים :האוצר הגדיל את הקרן ל-14 מילארד בדוק זכאותך
לרגל המצב משרד האוצר העמיד 14 מיליארד תוספת של 6 מיליארד לטובת עסקים נפגעי הקורונה וכעת קבלו גם ייעוץ לצמיחה מחודשת לעסק אופציה להגשת בקשת מימון כפולה מקרן ערבות מדינה ומקרן קורונה אופציה לגרייס לשנה עד חצי מיליון שח. 500,000 שח תנאי סף ללא חזרות המחאות מהחשבון בשנה האחרונה . ללא אכ"מ לבדיקת זכאות לחץ כאן יחד חוזרים לחיי שגרה חלקה הטבה משולשת ייעוץ +קרן ערבות מדינה+קרן קורונה השילוש שמבטיח לך חזרה וצמיחה עסקית לבדיקת זכאות לחץ כאן שולח: מטה עצמאים ופרילנסרים מ"עוף. כתובת השולח: שדרות עמיהוד 178, תל אביב. הסר (unsubscribe) אותי מרשימת התפוצה אם דיוור זה חשוד בעינייך כספאם, אנא ידע אותנו .
gcc-10-20200502 is now available
Snapshot gcc-10-20200502 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20200502/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 0118d0397f94c307b76aa14abec99347a93da621 You'll find: gcc-10-20200502.tar.xz Complete GCC SHA256=a72ba391b8114837403a24b0776201411530093b85c70fe56ee2a932cc1d581e SHA1=3d141b51985abcfd8476624a0324afba675f13f9 Diffs from 10-20200426 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
