From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Merging emacs-23 into trunk Date: Thu, 11 Nov 2010 11:28:39 +0900 Message-ID: <87wrokegq0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87bp5xg2b2.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1289443389 25063 80.91.229.12 (11 Nov 2010 02:43:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 11 Nov 2010 02:43:09 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 11 03:43:05 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 1PGN7w-0000xq-WD for ged-emacs-devel@m.gmane.org; Thu, 11 Nov 2010 03:43:05 +0100 Original-Received: from localhost ([127.0.0.1]:55893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGN7w-0003rW-7S for ged-emacs-devel@m.gmane.org; Wed, 10 Nov 2010 21:43:04 -0500 Original-Received: from [140.186.70.92] (port=53118 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGN7q-0003r4-Dn for emacs-devel@gnu.org; Wed, 10 Nov 2010 21:42:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGN7k-0004PT-DD for emacs-devel@gnu.org; Wed, 10 Nov 2010 21:42:58 -0500 Original-Received: from [130.158.254.171] (port=43432 helo=dmail02.cc.tsukuba.ac.jp) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGN7i-0004OM-M7; Wed, 10 Nov 2010 21:42:51 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp (unknown [130.158.254.130]) by dmail02.cc.tsukuba.ac.jp (Postfix) with ESMTP id 9747686EA29; Thu, 11 Nov 2010 11:26:39 +0900 (JST) Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 034492AF543; Thu, 11 Nov 2010 11:26:26 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id E99F32AF542; Thu, 11 Nov 2010 11:26:25 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id E715D3FA0513; Thu, 11 Nov 2010 11:26:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BED4A11EF63; Thu, 11 Nov 2010 11:28:39 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:132529 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Date: Wed, 10 Nov 2010 14:44:49 +0900 > > Cc: Stefan Monnier , emacs-devel@gnu.org > > > > Glenn Morris writes: > > > > > Can you make it just skip merging configure altogether? > > > > Not really. That's inherent in the philosophy of atomic commits and > > DAG-based merging. > > I don't follow. Do you have in mind a revision where configure was > committed together with other files? If so, I understand. But if it > was committed alone, what is the issue with atomic commits? The words "philosophy" and "and" in my statement are crucial. Of course we've learned how to split an atom. But then it's not an atom any more. Similarly, if you are going to commit changes to a generated file, then it should be committed with the source changes that generate them. The DAG-based merging helps to enforce this because there's no way that the VCS can determine that these changes are related via syntactic analysis, and humans won't always get it right. So DAG- based merging takes branch history as the proxy for relatedness. That's why workflows are so important. If you want a "better" notion of relatedness, use Darcs, which is designed to be more or less workflow-free (but in practice doesn't achieve that yet). The fact that Bazaar doesn't handle the situation very well is quite apart from the design philosophy.