From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: ChangeLog and commit messages Date: Mon, 19 Jun 2023 18:10:20 +0800 Message-ID: <87zg4v69v7.fsf@yahoo.com> References: <87a5wxb5sl.fsf.ref@yahoo.com> <87a5wxb5sl.fsf@yahoo.com> <837cs1p6bf.fsf@gnu.org> <875y7lb4k7.fsf@yahoo.com> <327d575ab075bf4e92ca00c11548a62458fec75b.camel@yandex.ru> <87r0q86zvd.fsf@yahoo.com> <87jzw06j1y.fsf@yahoo.com> <615704a18abdc3880a7e637e1903b81bcc9e50c8.camel@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33028"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 19 12:11:29 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qBBr5-0008Ov-H2 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Jun 2023 12:11:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBBqJ-0006yi-8s; Mon, 19 Jun 2023 06:10:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qBBqI-0006yZ-02 for emacs-devel@gnu.org; Mon, 19 Jun 2023 06:10:38 -0400 Original-Received: from sonic305-20.consmr.mail.ne1.yahoo.com ([66.163.185.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qBBqF-0004v4-1n for emacs-devel@gnu.org; Mon, 19 Jun 2023 06:10:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687169430; bh=G7LW//Koxolx3CJws8M6uoQsfgnDKpPG9nRiQ9Qo0MA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=kmiiwZ0j/0SUlQWC/V+79FOY0zzRF+x449fClIqq/cOukylPt+7ir697IoxmQY5m1p0g32NgQUejbvZJaorToRYgTqNsfMHvgic/s6r9+RH/QTXijgaAWiScd9fa5XXwtyfLMwcxkyN2c6d2nDF1sM0m+KnKS50+M4qWED0haePhkHYUc2TWLYzFsgD+zyMEz4jyk82otKdi+nnAKmKLvz4/1XBrgqnE6TZckVvuUyyesEfL9VHyaz+0wwQ4K4olHLHsMN9ee7442On7gv/5r1+yuYPw5k+GBkyIz+gXX9zvpQuo+L+H10l5MCl6RjGw8ysZkyDUjCiNkOztEufAfw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687169430; bh=vIv9FO4ANRpY3qHg6LRTN4mX6aNPYr3+af4fFdtnSDZ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=ZaY67gUIFRzTEM4BZnwgsbe/NBpn+rdtZgsgRcCNP8wQReSZi9pk00X1ItT+2/xvBXcbRF251SVpnQJaXiwac9glfwIsqvn7XrabjbxTQF2xKOMPuZ1Ls59uJbYLKshpVN10FfO/6nNBrUdr07jTqIhXZOAnSHmEsPrTdGBkWlAkDmdsMDjc93VL02DtVZgmV3dICnZLhMDrpVBqgDZInP1/+3Eqh+xCLZjBu3P3yXtlivDA16U1QvyF2SMkGJC/dpsSfI1FwsGnSuNAXCu5WBa35Ovf7bPK0nXLQ6q8fiJwn3OXycWjUqIF4F7zqcBnNwt4IOxu4eJMHTjcOzQ6xQ== X-YMail-OSG: mI2DMvMVM1l0_iHcQ9gJeU21Xeh_C0J6uHm5ySsTG761mLQ6t_sOGvMjUBZ2N4Z uOYaOEk8RyVi2xbMpuotesjZq_9jnnRRnBJC57w.ADV9..JBocIqemPifZsJoDyTG1m.G5blRp_A k6MGC4_31YpaZfvSQixCrXEC_pETREAbZqS_n.TTs1ike33KkGk3cGV1qtYECdxFS35MIQYfnRhZ d72vZO0fwkJJHVetV9xY9tmAdt7vur5hc_Qi7.vqWeQNnMThLWAnblKRy8hwCZ40UeYb7mEq0j02 5VZKXrQIKfaT89N6hjvcLk0PMi7EXiDJyTMZ3Ej_Z4mwkJgPqhbhn2FGVP8T7YNSecXITYoKW_my ..0xBuN87Zdqc5xU6SyEKASQNF7N1M8yDHRQI8SDCdKRDqpBr0gQKfHSJgm7AGEGuuHkLG1sHK_w ZSnREE6V1.XrROZLsT4Nn3VbVZZl3UI1.9bo2RCbm8noGtCD.7RCjCAL_S3FAnwQBTb8QKCog4TB jsEpU_7rw9y8KHOpscO_DZP6SXEV4TIDi7ui_n7b23SW5ix.BH1APAJuIp3PANPQ8dFcmohXDOIu lqM38mjBBCCg4iCHjvdvqYu0cDczHA_A_O6q5q1yvsLqaROgSkEThqbF3xERxS6Y2ZoiyQexHLuP IR1Ald.L0LAll3twa_r80WS8NMbs2U92TmnID7f0B307lzYC0WCW.sVqMRM.a9md1SCwJAB4WvEM n2Nopng8eu6b5tklY7Eq8MFOysn5kf9P1O92.hIPvrWs1.IXkuBYy6XoTiux2nOAVC7QsQDyvXGZ EQ30cBVvv53OSw9fgE4CDuh4_vcZc0bWC.s7J2pO2j X-Sonic-MF: X-Sonic-ID: df1bda01-ccad-4a14-b527-42f5fcc9e952 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Mon, 19 Jun 2023 10:10:30 +0000 Original-Received: by hermes--production-sg3-748897c457-ncjl6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0254bb67fac838dbe33f6d0fe5d8fcd7; Mon, 19 Jun 2023 10:10:25 +0000 (UTC) In-Reply-To: <615704a18abdc3880a7e637e1903b81bcc9e50c8.camel@yandex.ru> (Konstantin Kharlamov's message of "Mon, 19 Jun 2023 12:07:43 +0300") X-Mailer: WebService/1.1.21557 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.185.146; envelope-from=luangruo@yahoo.com; helo=sonic305-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307039 Archived-At: Konstantin Kharlamov writes: > (actually, it turns out I did work with SVN in my first job. But it wasn'= t the > only VCS we used, so I remember close to nothing about that =F0=9F=98=85) I'm thinking about RCS and its relatives. > Thanks, I see this commit, I'm looking. There are many different commits with this title. The last change was small, but others cannot be split up: look near the start of the branch point for an example. BTW, this brings up another problem with Git: it isn't possible to determine the branch point (or even the branch name) of a revision from the name of that revision alone. > So=E2=80=A6 From what I can see you have two separate changes in this com= mit. One is > "Only access width and height under lock", and another one=E2=80=A6 it is= some > algorithmic change in the `onLayout()`, which I didn't study too closely,= but > looking at the commit description I'm assuming it is "Send Expose upon la= yout > changes if the view has grown". > > The problem you have here with making up a title is because you've got two > different functional changes inside one commit. Note that you had no trou= ble > writing what has changed inside the commit message. So, had you separated= the > commit to two different ones, you would've gotten a commit title for free= just > by looking at your commit message =F0=9F=98=8A > > When someone mixes up different functional changes, all they can give as = a title > is just "Refactor foo.c" or "Rework bar" or "Fix buzz". When later lookin= g at > the shortlog these are pretty unhelpful titles, because it often says very > little about what really was done in the code. Which is the problem with the ``shortlog'' concept: detailed descriptions of these changes should be placed in ChangeLog, and the VCS should concentrate on tracking revisions to each file. > It is worth noting that although Emacs does allow mixing up many changes = in one, > a generally accepted good practice is to avoid that. Separating changes a= llows > for the author to easier figure out what went wrong, it makes review easi= er, and > when one have to revert an offending commit, it makes sure that unrelated= good > changes won't be reverted together with the ones that broke something. In= many > large projects such mixing up is not allowed and in code review the autho= r will > be asked to separate the changes. I don't think so. At my organization, which uses SVN, each new revision is required to change only one file, and updates to ChangeLog are performed separately after all edits are checked in and the corresponding files are unlocked. This is also the same policy that was used by Emacs development in the CVS days, I think. I don't know how to do this with Git, since it's not possible to update ChangeLog separately from file check-ins. > As an example, you can look at commit log in Mesa project=C2=B9. You can = see that > each title uniquely determines what was changed, and in many cases such c= ommits > are short. > > P.S: btw, in the article=C2=B2 by a kernel maintainer that I referred els= ewhere > there's also a good quote on your case: > >> If it's not possible to describe the high level change in a few words, i= t is > most likely too complex for a single commit > > 1: https://gitlab.freedesktop.org/mesa/mesa/-/commits/main > 2: http://who-t.blogspot.com/2009/12/on-commit-messages.html I've read the article, and I don't agree.