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: Sat, 02 Jan 2010 13:37:13 +0900 Message-ID: <87ws01m8au.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87637of4y8.fsf@kobe.laptop> <87oclfdzs2.fsf@kobe.laptop> <87hbr6jwsy.fsf@telefonica.net> <83my0yfc9g.fsf@gnu.org> <838wchgais.fsf@gnu.org> <878wchfxcn.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 1262406451 18051 80.91.229.12 (2 Jan 2010 04:27:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jan 2010 04:27:31 +0000 (UTC) Cc: ofv@wanadoo.es, Eli Zaretskii , Andreas Schwab , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 02 05:27:23 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 1NQvaE-0002nV-TZ for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 05:27:23 +0100 Original-Received: from localhost ([127.0.0.1]:54611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQvaE-0003a7-Tz for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 23:27:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQvaA-0003Zu-MH for emacs-devel@gnu.org; Fri, 01 Jan 2010 23:27:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQva6-0003Xe-Co for emacs-devel@gnu.org; Fri, 01 Jan 2010 23:27:18 -0500 Original-Received: from [199.232.76.173] (port=54532 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQva6-0003XU-6I for emacs-devel@gnu.org; Fri, 01 Jan 2010 23:27:14 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:44221) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQva4-0001mC-E9; Fri, 01 Jan 2010 23:27:12 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 57E977FFA; Sat, 2 Jan 2010 13:27:08 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 521D81A33D7; Sat, 2 Jan 2010 13:37:13 +0900 (JST) In-Reply-To: <878wchfxcn.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 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:119252 Archived-At: Karl Fogel writes: > There are other ways the system could work. IIUC, in git the commit > message is *not* part of the change's identity, No, in git the commit message is indeed part of the changes's identity. A commit is a strictly defined structure (that happens to be UTF-8 text with a final, free-form "comment" field), and the whole thing is hashed to get the SHA1 identifying the commit. What git has (and Mercurial, though implemented very differently) is tag *objects*. The tag object can contain arbitrary content (eg, a signature), but here it could be used in some conventional way (eg, by naming it "-log-" to record an edited message for commit . > But I don't know if git has a way of propagating those edits to > other clones; git commit --amend creates a new commit, propagated in the usual way for commits. git tag -a creates an annotated tag, propagated in the usual way for tags. > 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. The problem is that in a DVCS there is no reasonable way to propagate those changes, and it becomes an issue of what the "official" message for that commit is. Eg, suppose you tweak. Now different "official" messages are going to propagate -- some people already have that commit, and will *not* refetch it because the identity (SHA1) hasn't changed. Others will update or clone, and get it. In other words, in git the way to notify other clients that you've changed the commit message is to change the commit ID. This is true of all of the DVCSes I've used.