From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers Date: Fri, 19 Jun 2020 01:34:21 +0300 Message-ID: References: <87k12bdgx7.fsf@yahoo.com> <87r1wi7a8o.fsf@yahoo.com> <875zdteybt.fsf@runbox.com> <87368wrvf5.fsf@yahoo.com> <86k126d83n.wl-me@enzu.ru> <83pnbyckvv.fsf@gnu.org> <4923d7e98f5ed816a7569093dbc673153adcea88.camel@yandex.ru> <874krex73o.fsf@gmail.com> <87eeqctgb4.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="41909"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3 Cc: Eli Zaretskii , emacs-devel@gnu.org, Stefan Kangas , Dmitry Gutov To: Ricardo Wurmus , =?ISO-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 19 00:35:18 2020 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 1jm37u-000AoQ-M4 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 00:35:18 +0200 Original-Received: from localhost ([::1]:38454 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jm37t-00024g-K4 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Jun 2020 18:35:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jm37D-00012z-2r for emacs-devel@gnu.org; Thu, 18 Jun 2020 18:34:35 -0400 Original-Received: from forward104o.mail.yandex.net ([2a02:6b8:0:1a2d::607]:52699) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jm379-0000IN-Cu; Thu, 18 Jun 2020 18:34:34 -0400 Original-Received: from mxback10g.mail.yandex.net (mxback10g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:171]) by forward104o.mail.yandex.net (Yandex) with ESMTP id 9E33F9408FF; Fri, 19 Jun 2020 01:34:23 +0300 (MSK) Original-Received: from iva8-174eb672ffa9.qloud-c.yandex.net (iva8-174eb672ffa9.qloud-c.yandex.net [2a02:6b8:c0c:b995:0:640:174e:b672]) by mxback10g.mail.yandex.net (mxback/Yandex) with ESMTP id yCiW26iBgc-YN0qa4Yd; Fri, 19 Jun 2020 01:34:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592519663; bh=jq8VhMtgGyHePISGGNoAvBB1KWh7NOrGf7kMPqxr/C0=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=W9VQMGZuEsl6SD/B5ZTSRH5pmPm6WK5FgVzEz0qL8VJgZmE60HggxDwUGMAY7fq+f vdnKqCmMvE4INxaK79MMuxcxoJQPNB5YgzRjXiaVN/Pwjzc6nq//zuWyE80Bhpob67 zu7/ljzKboRzCMQWOvnO0uRgZSzpGDvx6nX+x6S4= Authentication-Results: mxback10g.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by iva8-174eb672ffa9.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 0EQzTMrln6-YM44bRKY; Fri, 19 Jun 2020 01:34:22 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <87eeqctgb4.fsf@elephly.net> Received-SPF: pass client-ip=2a02:6b8:0:1a2d::607; envelope-from=hi-angel@yandex.ru; helo=forward104o.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:252328 Archived-At: On Thu, 2020-06-18 at 19:49 +0200, Ricardo Wurmus wrote: > João Távora writes: > > > Konstantin Kharlamov writes: > > > > > Oh, sure I can be mistaken. I see you replied to Dmitry's email, I had a > > > follow- > > > up on it. Does my follow-up mail change your opinion, or perhaps do you > > > have > > > some example in mind that a good commit message without the list would not > > > solve? > > > > I might have read it. I'm not saying good commit messages are > > impossible without the summarizing list; I'm just saying it's a good > > thing to have, something I've grown accustomed to. When composing them, > > they're a good exercise in self-review. But of course there's more ways > > to skin a cat. This just happens to be the way we use here. > > > > It's not "for fun". Of course is a mental cost in composing them, > > especially if you don't do it often and use the friendly C-x 4 a > > shortcut. But there is a gain, too. > > I’d also like to note that this list can be invaluable when rebasing > commits and resolving conflicts. It’s not strictly necessary (just like > other parts of a version control workflow are not strictly necessary), > but it can serve as a sanity check in a time when the diff is not > authoritative as it is in flux. While it may be useful, but explicit examples may be more interesting. Right now when I read your text about this list in the context of resolving rebase conflicts, I only see the downside that if the conflict came up because a function was renamed, you need to go fix the commit message too. Even worse: if upon rebasing a function was renamed, you may not get any conflicts (i.e. because thunk you modified didn't include the beginning of the function), and now your commit message is broken without you even noticing. > An explanation as to why things were done is also very useful in those > cases, but an overview on the *conceptual* changes at the procedure > level (rather than the plain diff that’s only concerned with lines and > not with the context in which the changes occurred) provides additional > valuable information that the commit diff itself cannot provide. It is possible, it's just that I do not see this. Convincing someone that the commit message with the list provides more benefit than without it requires examples that make it explicit. So far the whole thread (both this part and the one with Dmitry) had only negative examples, i.e. why having the list is a burden to anyone. Let me sum up the positive mentions: so far, you just say it simplifies review for you, but I don't know your workflow, there may be many factors that make you assert that, which does not necessarily applies to everyone. Dmitry said the list makes better commit messages from novices, but again when I tried to dig deeper, that discussion died. You see, presence of negative examples and lack of positive ones doesn't make that look too convincing.