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: Incorrect merge Date: Wed, 03 Nov 2010 16:44:51 +0900 Message-ID: <87zktqj1fw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4CCEC526.3070502@cornell.edu> <87aaltc9rc.fsf@stupidchicken.com> <83pqup53qb.fsf@gnu.org> <83fwvk6arf.fsf@gnu.org> <87hbg0jxyu.fsf@uwakimon.sk.tsukuba.ac.jp> <87d3qnk9am.fsf@telefonica.net> <87k4kvwu6w.fsf@uwakimon.sk.tsukuba.ac.jp> <8762wfk5r0.fsf@telefonica.net> <87eib3wp4j.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwvjimg2.fsf@telefonica.net> <87d3qnwk0v.fsf@uwakimon.sk.tsukuba.ac.jp> <87wrovh2vl.fsf@telefonica.net> <871v73c775.fsf@uwakimon.sk.tsukuba.ac.jp> <87oca6hpld.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1288770220 22310 80.91.229.12 (3 Nov 2010 07:43:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 3 Nov 2010 07:43:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 03 08:43:26 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 1PDY0B-0003iW-Uw for ged-emacs-devel@m.gmane.org; Wed, 03 Nov 2010 08:43:24 +0100 Original-Received: from localhost ([127.0.0.1]:43051 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDY0B-00060d-E0 for ged-emacs-devel@m.gmane.org; Wed, 03 Nov 2010 03:43:23 -0400 Original-Received: from [140.186.70.92] (port=42920 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDY03-00060Y-PT for emacs-devel@gnu.org; Wed, 03 Nov 2010 03:43:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDY02-0003tG-FB for emacs-devel@gnu.org; Wed, 03 Nov 2010 03:43:15 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:35477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDY01-0003t7-UD for emacs-devel@gnu.org; Wed, 03 Nov 2010 03:43:14 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 74B9A2AF543; Wed, 3 Nov 2010 16:43:11 +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 5EE032AF542; Wed, 3 Nov 2010 16:43:11 +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 5A1933FA04DF; Wed, 3 Nov 2010 16:43:11 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 219CF1A3EDD; Wed, 3 Nov 2010 16:44:51 +0900 (JST) In-Reply-To: <87oca6hpld.fsf@telefonica.net> 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:132315 Archived-At: =D3scar Fuentes writes: > "Stephen J. Turnbull" writes: >=20 > [snip] >=20 > > Your way requires all committers who fix bugs to worry about which > > branch to commit to. >=20 > Yes, exactly as it happens right now. Which is missing the point. One point of the svnmerge-based workflow is that the branch to commit doesn't really matter, and the decision to block merges/cherry-picks made after inspecting the commit. So the svnmerge approach is *better* in this respect. But the main point is that cherry-picking, which is a natural workflow in this context in general, and the historical practice of Emacs, is well-supported by svnmerge. The point of the common-fixes workflow is to (unnaturally) avoid cherry-picking. But (a) this is awkward for the workers, especially at first, and (b) it is a change. As I've said before, I personally use "emphemeral" branches in git for this situation. And I'm sure that for many communities, the common- fixes approach works well too. But the Python community strongly prefers the svnmerge approach (porting svnmerge to Mercurial is one of the blockers on their migration), and my feeling is that the Emacs community is similar to the Python community in this respect. I don't know about others, but you don't need to prove to me that your approach works. Although I haven't actually used it in practice, the theory looks good enough. The question I have is whether it's well- adapted to Emacs. So far the Emacs maintainers (including Richard) have been *very* conservative about changes to workflow. svnmerge (or a port of it) *supports* the current workflow. That's going to be tough to beat.