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: Workflow to accumulate individual changes? Date: Fri, 01 Jan 2010 22:49:00 +0900 Message-ID: <878wcindf7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fx6sm8yl.fsf@telefonica.net> <873a2slzrr.fsf@telefonica.net> <83ws03db8v.fsf@gnu.org> <87skarapxo.fsf@red-bean.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262353172 25583 80.91.229.12 (1 Jan 2010 13:39:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jan 2010 13:39:32 +0000 (UTC) Cc: ofv@wanadoo.es, Juanma Barranquero , Eli Zaretskii , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 01 14:39:24 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.50) id 1NQhiq-0004id-W4 for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 14:39:21 +0100 Original-Received: from localhost ([127.0.0.1]:59050 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQhir-0002Q7-Fa for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 08:39:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQhik-0002PF-Jx for emacs-devel@gnu.org; Fri, 01 Jan 2010 08:39:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQhif-0002NC-L2 for emacs-devel@gnu.org; Fri, 01 Jan 2010 08:39:14 -0500 Original-Received: from [199.232.76.173] (port=37450 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQhif-0002Mn-CF for emacs-devel@gnu.org; Fri, 01 Jan 2010 08:39:09 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:38269) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NQhic-0000xk-Ax; Fri, 01 Jan 2010 08:39:06 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQhib-00021Z-0l; Fri, 01 Jan 2010 08:39:05 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 102A01535A8; Fri, 1 Jan 2010 22:38:51 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A34E61A33D7; Fri, 1 Jan 2010 22:49:00 +0900 (JST) In-Reply-To: <87skarapxo.fsf@red-bean.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by monty-python.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:119202 Archived-At: Karl Fogel writes: > Juanma Barranquero writes: > >Well, I can agree with that if you can agree that perhaps rebase > >*could be* the best fix after all... ;-) > > I've never used 'bzr rebase', and have no competency to evaluate the > arguments either way here, but... wouldn't something would smell fishy > if rebase were part of our regular workflow? That somehow seems wrong. No, it's a matter of style. Let me summarize: 1. Everybody agrees that rebasing a branch which is not 100% private is problematic. 2. Some people like rebasing private branches before pushing them, basically because it makes the history more linear. (git people generally do.) Making the history more linear often makes bisection more effective, because (except for the initial graft) the patches tend to be smaller and localize the defect better. 3. Some people dislike rebasing private branches, because it makes the history more linear. (bzr people generally do.) There are two reasons typically given: a. Work done concurrently is "misrepresented" as being sequential. I suspect these people generally have an intuition of b, but don't express it that way. b. It's easy to think that all commits have properly tested because all commits on each (original) branch and the tip have been tested, but that is false. In fact, all commits between the graft point and the tip need to be retested. Of course, "need" is assuming a "test every commit" discipline. There's a reason that is not typically given, too. c. In some DVCSes, rebase destroys history. It is in general not possible to recover the original branch from a rebase given only the "after" DAG. In bzr a rebase makes recovering the original branch a task for someone familiar with the internals. (It may even be impossible in some cases, I don't know enough about the internals to say.) If it's not obvious, let me state that I am biased toward the pro-rebase side. But that's a matter of taste.