From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Koch Subject: Re: RFE: support change-id generation natively Date: Mon, 21 Oct 2013 20:29:00 +0200 Message-ID: <201310212029.01589.thomas@koch.ro> References: <2127507934.9293293.1382367063640.JavaMail.root@openwide.fr> <1382370119.28365.36627953.50C0496E@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Jeremy Rosen , git@vger.kernel.org To: james.moger@gitblit.com X-From: git-owner@vger.kernel.org Mon Oct 21 20:29:13 2013 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VYKE5-00026L-0F for gcvg-git-2@plane.gmane.org; Mon, 21 Oct 2013 20:29:13 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751548Ab3JUS3I (ORCPT ); Mon, 21 Oct 2013 14:29:08 -0400 Received: from koch.ro ([88.198.2.104]:60154 "EHLO koch.ro" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423Ab3JUS3H (ORCPT ); Mon, 21 Oct 2013 14:29:07 -0400 Received: from 44-25.106-92.cust.bluewin.ch ([92.106.25.44] helo=x121eofhwr1202.localnet) by koch.ro with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VYKDw-0000Hw-ME; Mon, 21 Oct 2013 20:29:04 +0200 User-Agent: KMail/1.13.7 (Linux/3.10-0.bpo.3-amd64; KDE/4.8.4; x86_64; ; ) In-Reply-To: <1382370119.28365.36627953.50C0496E@webmail.messagingengine.com> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Monday, October 21, 2013 05:41:59 PM james.moger@gitblit.com wrote: > The change-id is exactly like a commit-id, it is an SHA-1 value, but it > is a constant embedded in the commit message. As I understand, a UUID could also be used for the same purbose as the change- id. How is the change-id generated by the way? Would it be a good english name to call it enduring commit identifier? I had an usage example for such identifiers last week while helping to rebase and merge a few too long standing feature branches. After a while we noticed, that a few commits where already cherry-picked in a slightly different form and with different commit message to the integration branch. If those commit had enduring identifiers, it would have been easier to spot this. Git already has functionality to identify commits that have already been cherry-picked or merged in a branch and thus skips them in a rebase. Could this functionality benefit from an enduring commit identifier? Best regards, Thomas Koch