From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Workflow to accumulate individual changes? Date: Fri, 01 Jan 2010 14:18:00 -0500 Message-ID: <878wchfxcn.fsf@red-bean.com> References: <87637of4y8.fsf@kobe.laptop> <87oclfdzs2.fsf@kobe.laptop> <87hbr6jwsy.fsf@telefonica.net> <83my0yfc9g.fsf@gnu.org> <838wchgais.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262373504 12510 80.91.229.12 (1 Jan 2010 19:18:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jan 2010 19:18:24 +0000 (UTC) Cc: ofv@wanadoo.es, Eli Zaretskii , emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 01 20:18:16 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 1NQn0p-0002K1-T8 for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 20:18:16 +0100 Original-Received: from localhost ([127.0.0.1]:54191 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQn0q-0001CZ-9c for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 14:18:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQn0k-0001Bo-Op for emacs-devel@gnu.org; Fri, 01 Jan 2010 14:18:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQn0g-0001AK-CO for emacs-devel@gnu.org; Fri, 01 Jan 2010 14:18:10 -0500 Original-Received: from [199.232.76.173] (port=49618 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQn0g-0001AH-6d for emacs-devel@gnu.org; Fri, 01 Jan 2010 14:18:06 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:57344) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NQn0e-0007cm-3i; Fri, 01 Jan 2010 14:18:04 -0500 Original-Received: from localhost ([127.0.0.1]:54846 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.71) (envelope-from ) id 1NQn0a-0003G5-Kg; Fri, 01 Jan 2010 13:18:00 -0600 In-Reply-To: (Andreas Schwab's message of "Fri, 01 Jan 2010 15:48:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) 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:119216 Archived-At: Andreas Schwab writes: >Eli Zaretskii writes: > >> A commit message is not history > >It is an integral part of the commit. This is an old debate in the DVCS world. The issue is that changes are distributed and there is no "master copy" of a given change; instead, there are many copies of the same change, and you can tell they're the same because they all have the same unique id (and same contents). In CVS, the master copy is always in the repository and there is exactly one repository. So if you want to read log messages, you do 'cvs log' and it contacts the repository (or, in Emacs's case, 'cvs update' gets updates to the ChangeLog files, but that also contacts the repository). In Bzr, the savannah trunk branch is sort of the equivalent CVS's "the repository"... but the changes in that branch are replicated among hundreds or thousands of developers' local branches. If you tweak a commit message on the savannah branch, bzr has no mechanism for conveying that tweak to the other branches, because the commit message is considered part of the change, just like the diff. Tweak the commit message and you've tweaked the change -- it's no longer the same change. There are other ways the system could work. IIUC, in git the commit message is *not* part of the change's identity, it's just attached to the change, so you can edit the message later. But I don't know if git has a way of propagating those edits to other clones; nor do I know what git would do if two different clones tweak a commit message for the "same" change in two different ways and then one of them has to receive the other's edits. Is there conflict resolution on "out-of-band" data, and if so, how would it work? Perhaps the difficulty of that question is why bzr doesn't support this. In any case, IMHO it is a minor feature regression that we can no longer tweak log messages after the fact, but it's not a huge problem. -Karl