From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH] diff: add a config option to control orderfile Date: Wed, 18 Sep 2013 00:03:25 +0300 Message-ID: <20130917210325.GA22511@redhat.com> References: <20130917164226.GB20672@redhat.com> <20130917172829.GA21121@redhat.com> <20130917201401.GA22000@redhat.com> <20130917201604.GA22008@redhat.com> <20130917201828.GC16860@sigill.intra.peff.net> <20130917203807.GA22059@redhat.com> <20130917205615.GA20178@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Junio C Hamano , git@vger.kernel.org To: Jeff King X-From: git-owner@vger.kernel.org Tue Sep 17 23:01:33 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 1VM2Or-0003qC-Ab for gcvg-git-2@plane.gmane.org; Tue, 17 Sep 2013 23:01:33 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753458Ab3IQVB3 (ORCPT ); Tue, 17 Sep 2013 17:01:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15954 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753316Ab3IQVB3 (ORCPT ); Tue, 17 Sep 2013 17:01:29 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8HL1CXY027906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 17:01:12 -0400 Received: from redhat.com (vpn1-4-202.ams2.redhat.com [10.36.4.202]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id r8HL1AFa006412; Tue, 17 Sep 2013 17:01:11 -0400 Content-Disposition: inline In-Reply-To: <20130917205615.GA20178@sigill.intra.peff.net> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote: > On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote: > > > > A problem with both schemes, though, is that they are not > > > backwards-compatible with existing git-patch-id implementations. > > > > Could you clarify? > > We never send patch IDs on the wire - how isn't this compatible? > > I meant that you might be comparing patch-ids generated by different > implementations, or across time. There are no dedicated tools to do so, > but it is very easy to do so with standard tools like "join". > > For example, you can do: > > patch_ids() { > git rev-list "$1" | > git diff-tree --stdin -p | > git patch-id | > sort > } > > patch_ids origin..topic1 >us > patch_ids origin..topic2 >them > > join us them | cut -d' ' -f2-3 > > to get a list of correlated commits between two branches. If the "them" > was on another machine with a different implementation (or is saved from > an earlier time), your patch-ids would not match. > > It may be esoteric enough not to worry about, though. By far the most > common use of patch-ids is going to be in a single "rev-list > --cherry-pick" situation where you are trying to omit commits during > a rebase. > > I am mostly thinking of the problems we had with the "kup" tool, which > expected stability across diffs that would be signed by both kernel.org. > But as far as I know, they do not use patch-id. We can always do a compatibility option. --order-sensitive ? --ignore-order ? > More details in case you > are curious (including me arguing that we should not care, and it is > kup's problem!) are here: > > http://thread.gmane.org/gmane.comp.version-control.git/192331/focus=192424 > > rerere is mentioned in that thread, but I believe that it does its own > hash, and does not rely on patch-id. > > -Peff I think so too.