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: Locks on the Bzr repository Date: Sun, 22 Aug 2010 20:14:52 +0900 Message-ID: <87fwy67vbn.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4C6D56DB.7040703@swipnet.se> <4C6D8EC5.7040901@swipnet.se> <4C6E1F0A.7070506@swipnet.se> <837hjlr78p.fsf@gnu.org> <87zkwhtws5.fsf@uwakimon.sk.tsukuba.ac.jp> <83tymppj62.fsf@gnu.org> <871v9t8klf.fsf@uwakimon.sk.tsukuba.ac.jp> <83lj81pazq.fsf@gnu.org> <83aaogpcbu.fsf@gnu.org> <87vd737pxd.fsf@uwakimon.sk.tsukuba.ac.jp> <83pqxboi38.fsf@gnu.org> <87r5hr6qvf.fsf@uwakimon.sk.tsukuba.ac.jp> <87hbin6m04.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 1282475911 30929 80.91.229.12 (22 Aug 2010 11:18:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 Aug 2010 11:18:31 +0000 (UTC) Cc: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 22 13:18:28 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 1On8ZI-0001xo-2Y for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 13:18:28 +0200 Original-Received: from localhost ([127.0.0.1]:55196 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On8ZH-0007nW-2U for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 07:18:27 -0400 Original-Received: from [140.186.70.92] (port=37069 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On8Z9-0007nR-D7 for emacs-devel@gnu.org; Sun, 22 Aug 2010 07:18:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1On8Z3-0008Gn-U4 for emacs-devel@gnu.org; Sun, 22 Aug 2010 07:18:19 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:55081) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1On8Yw-0008Fy-7B; Sun, 22 Aug 2010 07:18:06 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1430BF4003; Sun, 22 Aug 2010 20:18:04 +0900 (JST) Original-Received: from mgmt2.sk.tsukuba.ac.jp (unknown [130.158.97.224]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 03C1AF4002; Sun, 22 Aug 2010 20:18:04 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id F309897030D; Sun, 22 Aug 2010 20:18:03 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F0B091A2C38; Sun, 22 Aug 2010 20:14:52 +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, seldom 2.4 (older, 4) 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:129025 Archived-At: Eli Zaretskii writes: > Code is seldom reviewed in Emacs, the only exceptions are > contributors who explicitly ask for a review. Uh.... :-) > And there's the issue of conflicts when you resync next (unless the > committed fix is textually identical to the one in your WT). I haven't noticed this being an issue. It was a massive pain in CVS, but with git at least you revert the transaction causing conflicts and either do a reverse cherry-pick or an interactive rebase on your tree. Then redo the pull/merge/update. Usually not a big deal, even if it's buried many commits deep in the DAG. OTOH, if there is reason to insist on your own patch (either it's better or it's at least as good and you have additional "important" patches that depend on your version), then you clone the mainline, undo the conflicting patch, and merge with your "better" branch. I can't say this will always work, but it has worked for me on the occasions I've tried it.