From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Workflow to accumulate individual changes? Date: Thu, 31 Dec 2009 05:26:17 -0500 Message-ID: References: <87fx6sm8yl.fsf@telefonica.net> <873a2slzrr.fsf@telefonica.net> <83ws03db8v.fsf@gnu.org> <87d41vlok4.fsf@telefonica.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1262255201 25098 80.91.229.12 (31 Dec 2009 10:26:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Dec 2009 10:26:41 +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 11:26:34 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 1NQIEg-0006Q1-ES for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 11:26:30 +0100 Original-Received: from localhost ([127.0.0.1]:51460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQIEg-0002kE-Nr for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 05:26:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQIEa-0002k0-1n for emacs-devel@gnu.org; Thu, 31 Dec 2009 05:26:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQIEU-0002jT-Tu for emacs-devel@gnu.org; Thu, 31 Dec 2009 05:26:23 -0500 Original-Received: from [199.232.76.173] (port=55587 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQIEU-0002jQ-Kv for emacs-devel@gnu.org; Thu, 31 Dec 2009 05:26:18 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40924) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQIEU-0000gl-5E for emacs-devel@gnu.org; Thu, 31 Dec 2009 05:26:18 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1NQIET-0007UE-SY; Thu, 31 Dec 2009 05:26:17 -0500 In-reply-to: <87d41vlok4.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar_Fuentes?= on Thu, 31 Dec 2009 06:06:51 +0100) X-detected-operating-system: by monty-python.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:119132 Archived-At: > From: =?utf-8?Q?=C3=93scar_Fuentes?= > Date: Thu, 31 Dec 2009 06:06:51 +0100 > > > ChangeLog files will present a problem for feature branches and > > quick-fix branches alike. > > Very true. On Juanma's case, if he accumulated a signicant number of > small changes, rebasing can save quite a bit of work compared to > creating a patch, applying it, re-writing a commit message and commit > for each change. Or merging one change, edit the ChangeLog, write the > commit message, commit and repeat for the next change (which possibly is > the most orthodox solution and recommendable if the amount of changes is > moderate.) It's an annoyance, yes, but not a large one. After all, you have everything right there in the same Emacs session. How hard is it to reorder a few log entries? > > Though an annoyance, I don't see how it is a problem significant > > enough to recommend rebase as the main vehicle of routine work, given > > the downside of rebasing (rewriting history etc.). > > The history is rewritten at Juanma's end. For the rest of users, the > final result is indistinguishable of the case where Juanma commits a > series of small changes on a fast sequence. Unless I misunderstood what I've read, that's not accurate: the final result _will_ matter for others, if and when those others will want at some point in the future to dig into Juanma's changes and understand how the final code came into existence -- which parts of it were written by Juanma, which ones by others, and which ones are result of bzr merges. In fact, Juanma himself may wish to do this kind of archeology some time after committing. > The ChangeLog is a big incovenience for working locally while upstream > access is restricted. In my work on bidi Emacs, I keep a separate ChangeLog file precisely for that reason. With CVS, it was simply an unversioned file. With bzr, I will probably have it committed to my local branch, but will delete it after copying (some of) its contents to the upstream logs when the feature is merged with upstream. If someone has a better idea for a long-term feature branch, I'm all ears.