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: merge-commits policy Date: Tue, 17 May 2011 20:57:59 +0300 Message-ID: <83boz1gqfs.fsf@gnu.org> References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> <4DD0B70F.7090801@cs.ucla.edu> <83mxindqmp.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1305655094 20232 80.91.229.12 (17 May 2011 17:58:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 17 May 2011 17:58:14 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 17 19:58:10 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 1QMOX3-00060n-Vm for ged-emacs-devel@m.gmane.org; Tue, 17 May 2011 19:58:10 +0200 Original-Received: from localhost ([::1]:42315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMOX3-0000fo-9t for ged-emacs-devel@m.gmane.org; Tue, 17 May 2011 13:58:09 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMOX0-0000fh-Gd for emacs-devel@gnu.org; Tue, 17 May 2011 13:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMOWz-0004aq-0U for emacs-devel@gnu.org; Tue, 17 May 2011 13:58:06 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:53206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMOWy-0004ag-Nl for emacs-devel@gnu.org; Tue, 17 May 2011 13:58:04 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LLC00J00PRYYT00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 17 May 2011 20:58:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.254.13]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LLC00II9PWNP7C0@a-mtaout22.012.net.il>; Tue, 17 May 2011 20:58:00 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:139466 Archived-At: > From: Stefan Monnier > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Tue, 17 May 2011 10:42:32 -0300 > > > 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. Except that emacs-23 is a public branch which can be examined directly, unlike private branches that cannot. > > 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. Exactly: harder. > As would searching the ChangeLog rather than "bzr log". Unfortunately, only some of these updates are reflected in doc/misc/ChangeLog, and some aren't, so this is unreliable. > Personally I would use C-x v l and/or C-x v g from the texinfo.tex buffer. "C-x v l" takes ages for veteran files (because texinfo.tex was "cvs mv"ed, it appears to have been born relatively recently, so it is spared this problem). To be efficient, you need to run "bzr log" for a certain range of revisions. "C-x v g" is fine only the first time. Once you find the latest revision that modified some line, and need to see the previous revisions that modified the same line, you need to find the exact revision number and use "-r before:", or else you will miss some of the change history, e.g. if there were more than one change on the branch before it was merged. Like I said: possible, but harder. > > 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. Thanks, I hope this is acceptable.