From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Header lines of commit messages Date: Sat, 26 Jun 2010 18:01:52 +0300 Message-ID: <83hbkpdehr.fsf@gnu.org> References: <83r5jucbvq.fsf@gnu.org> <87k4pldikb.fsf@elegiac.orebokech.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1277564440 16479 80.91.229.12 (26 Jun 2010 15:00:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Jun 2010 15:00:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Romain Francoise Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 26 17:00:36 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OSWrx-000512-WB for ged-emacs-devel@m.gmane.org; Sat, 26 Jun 2010 17:00:34 +0200 Original-Received: from localhost ([127.0.0.1]:32949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OSWrv-0007hV-Kq for ged-emacs-devel@m.gmane.org; Sat, 26 Jun 2010 11:00:31 -0400 Original-Received: from [140.186.70.92] (port=53222 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OSWrr-0007hO-1y for emacs-devel@gnu.org; Sat, 26 Jun 2010 11:00:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OSWrp-0001fE-Kz for emacs-devel@gnu.org; Sat, 26 Jun 2010 11:00:26 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59742) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OSWrp-0001f1-AY for emacs-devel@gnu.org; Sat, 26 Jun 2010 11:00:25 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L4M00200MVM3D00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 26 Jun 2010 17:59:51 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.155.52]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L4M00G3KMZPUDR0@a-mtaout22.012.net.il>; Sat, 26 Jun 2010 17:59:50 +0300 (IDT) In-reply-to: <87k4pldikb.fsf@elegiac.orebokech.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126439 Archived-At: > From: Romain Francoise > Date: Sat, 26 Jun 2010 15:33:56 +0200 > Cc: emacs-devel@gnu.org > > Eli Zaretskii writes: > > > The header line that summarizes the commit conveys useless > > information. It should state the essence of the change instead, so > > that people who use "bzr log --line" will be able to grasp the purpose > > of the change without looking at the full text. > > For changes that are made directly in Emacs, yes. > > In this case, org-mode is maintained outside Emacs and I'm just > merging a fix from the original repository. I don't see why this is different. > If we followed the logic that the header line should always > accurately describe the change, we wouldn't allow commits like these > either: > > 100593: Romain Francoise 2010-06-12 Synch with Gnus trunk. > 100575: Katsumi Yamaoka 2010-06-10 [merge] Synch with Gnus trunk. > 100541: Katsumi Yamaoka 2010-06-07 [merge] Synch with Gnus trunk. > 100498: Katsumi Yamaoka 2010-06-02 [merge] Synch with Gnus trunk. For merges that bring in a lot of unrelated changes, this is acceptable, because there's no practical way to come up with a meaningful header line. But in your case, you cherry-picked a single change set that can be summarized with a short header line. > the fact that it's a single commit rather than a bunch of > unrelated changes doesn't really change anything. I think it does: describing this single commit with a short meaningful text is possible and reasonably easy. > In an ideal world Emacs would be using Git, and org-mode, Gnus, ERC > and others would just be submodules pointing to a given branch of > the original repository. Then doing such a merge would not lose > information. But we're stuck with bzr + patch. No, in an ideal world, org-mode, Gnus, ERC, etc. would be using Bazaar, and Bazaar would be fast enough for them to have no reason to use Git. In any case, I don't see a reason to punish Emacs for using Bazaar. (Your text sounds like saying: you decided to use Bazaar, so now you get to pay for it.) But that has nothing to do with the issue at hand. I'm sorry that you disagree with me, because it means more meaningless commit messages are to come.