From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Workflow to accumulate individual changes? Date: Thu, 31 Dec 2009 02:33:39 +0100 Message-ID: References: <87fx6sm8yl.fsf@telefonica.net> <873a2slzrr.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1262224104 30054 80.91.229.12 (31 Dec 2009 01:48:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Dec 2009 01:48:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 31 02:48:16 2009 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 1NQA9A-0000y6-HF for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 02:48:16 +0100 Original-Received: from localhost ([127.0.0.1]:47860 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQA9A-0002aL-RU for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 20:48:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQ9vR-00067P-Vg for emacs-devel@gnu.org; Wed, 30 Dec 2009 20:34:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQ9vM-00063y-VC for emacs-devel@gnu.org; Wed, 30 Dec 2009 20:34:05 -0500 Original-Received: from [199.232.76.173] (port=40625 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQ9vM-00063l-PJ for emacs-devel@gnu.org; Wed, 30 Dec 2009 20:34:00 -0500 Original-Received: from mail-bw0-f215.google.com ([209.85.218.215]:59437) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQ9vM-00035d-Cs for emacs-devel@gnu.org; Wed, 30 Dec 2009 20:34:00 -0500 Original-Received: by bwz7 with SMTP id 7so8638978bwz.26 for ; Wed, 30 Dec 2009 17:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/2Q+kuLzqtw+q8EofT0whFLSDGY9zf4VJFZW3lt5Ef4=; b=Y3kASk1qRa4nBsB6ygaTFVwdkQ1mdUCn6twdSVb4RZd5mWtqlkiIA1PVaWLAm1x0EX SDo4joBCz8Sbp2vRrUk1V94i/7z1S9aPOcdqoOsT4DzCRq0rSrxYBXhuzsORi4pPHt+r qI57V5nj8wS39v73kC2//vabFgcokWUPbrJA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=FYg1JS9ZE2NIeeG6PwWjeNR556besbajU+QQVwb/KyPsbA64ydEbjNwSgHYqsAtiF4 17wt+hn7Zcv7RKlH/JY/4L+67DloMuhjiTyXyFw0x1ukvDxZYuS9+PmxTKui5rWhWb/k 2dxXDoQRRT6vc+43jSohGxhO4O5mKKymAhq6E= Original-Received: by 10.204.34.10 with SMTP id j10mr3911103bkd.77.1262223239162; Wed, 30 Dec 2009 17:33:59 -0800 (PST) In-Reply-To: <873a2slzrr.fsf@telefonica.net> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:119094 Archived-At: On Thu, Dec 31, 2009 at 02:04, =C3=93scar Fuentes wrote: > If somehow the rebase finds a conflict on the ChangeLog for every > rebased revision, you could fix the dates. I know by experience that > Subversion generates a conflict every time two changes append lines to a > file. If bzr generates a conflict when two changes happen at the top of > the ChangeLog file, you could arrange things for this to happen: the > first revision should conflict right away; for the second revision to > conflict, you'll need to leave the top of the ChangeLog on a way that it > can't merge the second revision, etc. I'd rather have Bazaar not to generate a conflict for changes at the top of the file; it's common enough, and I've had my share of them on CVS :-) That said, what you propose could work, but of course it's quite hackish. Let's hope someday the rebase plugin will grow an option to rebase interactively, stopping before the commit. Juanma