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: Sat, 02 Jan 2010 00:12:12 -0500 Message-ID: <87iqbl9jkj.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> <878wchfxcn.fsf@red-bean.com> <874on537yy.fsf@iki.fi> <87my0xega6.fsf@red-bean.com> <87zl4x1qjl.fsf@iki.fi> <87vdflm781.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1262409156 22010 80.91.229.12 (2 Jan 2010 05:12:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jan 2010 05:12:36 +0000 (UTC) Cc: ofv@wanadoo.es, Eli Zaretskii , Teemu Likonen , Andreas Schwab , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 02 06:12:28 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 1NQwHr-0004h9-Tw for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 06:12:28 +0100 Original-Received: from localhost ([127.0.0.1]:43050 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQwHs-0003fH-75 for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 00:12:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQwHm-0003dT-6J for emacs-devel@gnu.org; Sat, 02 Jan 2010 00:12:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQwHh-0003YD-BK for emacs-devel@gnu.org; Sat, 02 Jan 2010 00:12:21 -0500 Original-Received: from [199.232.76.173] (port=48893 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQwHh-0003Y7-6d for emacs-devel@gnu.org; Sat, 02 Jan 2010 00:12:17 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:47153) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NQwHf-0004bG-8N; Sat, 02 Jan 2010 00:12:15 -0500 Original-Received: from localhost ([127.0.0.1]:42994 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.71) (envelope-from ) id 1NQwHd-0004y5-0c; Fri, 01 Jan 2010 23:12:13 -0600 In-Reply-To: <87vdflm781.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sat, 02 Jan 2010 14:00:30 +0900") 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:119255 Archived-At: "Stephen J. Turnbull" writes: >Teemu Likonen writes: > > No problem. I'll still repeat that it's indeed misinformation. Here's a > > raw content of a certain commit object in Emacs Git repository (the > > four-space indent is by me): > >cat'ing the object doesn't prove anything. The header content is >easily separable from the commit message, and in theory you could >generate the SHA1 based on the header only. (I can't imagine Linus >doing such a thing, but it would immediately occur to most Emacs >hackers.) Heh. I followed up in private mail to Teemu saying the same thing. >Here's an experimental proof: > ># Verify identity. >$ git rev-parse HEAD >f008c025d04f4bcec79f2bb463589461d95a3154 >$ git cat-file commit HEAD | git hash-object --stdin -t commit >f008c025d04f4bcec79f2bb463589461d95a3154 > ># Verify difference -- I happen to know that the word "Update" occurs ># uniquely in the comment portion of this commit. >$ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \ > | git hash-object --stdin -t commit >ff2c9790c738d10205086a12ce394069ceccbb83 Now *that's* the proof we needed. Thanks. It would be very winning if some DVCS would a) Allow tweaking commit messages b) Version those tweaks c) Propagate those tweaks to other branches whenever the other branch receives data from the tweaked branch d) Have a conflict resolution mechanism for when different tweaks collide This is a tall order, however. I'm not surprised no DVCS (AFAIK) does it. -K