From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: merge-commits policy Date: Tue, 17 May 2011 10:42:32 -0300 Message-ID: References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> <4DD0B70F.7090801@cs.ucla.edu> <83mxindqmp.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305639770 19657 80.91.229.12 (17 May 2011 13:42:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 17 May 2011 13:42:50 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 17 15:42:44 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QMKXn-0000sV-Ts for ged-emacs-devel@m.gmane.org; Tue, 17 May 2011 15:42:40 +0200 Original-Received: from localhost ([::1]:36062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMKXn-0007K6-8y for ged-emacs-devel@m.gmane.org; Tue, 17 May 2011 09:42:39 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMKXk-0007Jz-Ou for emacs-devel@gnu.org; Tue, 17 May 2011 09:42:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMKXj-0000BD-E7 for emacs-devel@gnu.org; Tue, 17 May 2011 09:42:36 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:36010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMKXj-0000B9-BS for emacs-devel@gnu.org; Tue, 17 May 2011 09:42:35 -0400 Original-Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:45658 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QMKXi-00032s-UX; Tue, 17 May 2011 09:42:35 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 754F866140; Tue, 17 May 2011 10:42:32 -0300 (ART) In-Reply-To: (Eli Zaretskii's message of "Tue, 17 May 2011 06:30:50 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139462 Archived-At: >> I, for one, do. texinfo.tex is not a file we maintain, so I fully >> expect to find its changes in some kind of "sync from outside" commit. > Well, then maybe replace "no one will ever" with "many people will not". > However, I think even you will not expect to find that texinfo.tex was > updated in commits such as these two: > revno: 103360 [merge] > committer: Paul Eggert > branch nick: trunk > timestamp: Sun 2011-02-20 00:48:52 -0800 > message: > Merge: Import crypto/md5 and stdint modules from gnulib. > -------------------------------------------------------- > revno: 103104 [merge] > committer: Paul Eggert > branch nick: trunk > timestamp: Thu 2011-02-03 11:30:24 -0800 > message: > merge: allow C code to suppress warnings about ignored return values > ------------------------------------------------------------ The same holds for "merge from emacs-23" or any other merge for that matter. > Yes, invoking "bzr log" with the -n0 or --include-merges switch would > have shown that the second one of these two mentions texinfo.tex in > its branch commit. Exactly. As would searching the ChangeLog rather than "bzr log". Personally I would use C-x v l and/or C-x v g from the texinfo.tex buffer. > different features and unrelated bugfixes. If you regard any "sync > from gnulib" as a single self-contained changeset, then at least it > should be committed to mainline separately from other changes. That would make sense, yes. Although in the case of gnulib, most "syncs" happen because we import yet another module, so it's OK to do both "import foo module" and "sync" at the same time, but indeed, the commit message should indicate that a sync with gnulib took place. Stefan