From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 1/3] patch-id: make it stable against hunk reordering Date: Thu, 27 Mar 2014 20:45:15 +0200 Message-ID: <20140327184515.GA4056@redhat.com> References: <1395912239-29663-1-git-send-email-mst@redhat.com> <20140327175746.GA3853@redhat.com> <20140327183917.GA3980@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org, jrnieder@gmail.com, peff@peff.net To: Junio C Hamano X-From: git-owner@vger.kernel.org Thu Mar 27 19:46:29 2014 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 1WTFJs-0001Hf-Ie for gcvg-git-2@plane.gmane.org; Thu, 27 Mar 2014 19:46:28 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756946AbaC0SqS (ORCPT ); Thu, 27 Mar 2014 14:46:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52945 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756825AbaC0SqR (ORCPT ); Thu, 27 Mar 2014 14:46:17 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2RIiwvi022145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 14:44:58 -0400 Received: from redhat.com (vpn1-7-130.ams2.redhat.com [10.36.7.130]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id s2RIiua7005898; Thu, 27 Mar 2014 14:44:56 -0400 Content-Disposition: inline In-Reply-To: <20140327183917.GA3980@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Mar 27, 2014 at 08:39:17PM +0200, Michael S. Tsirkin wrote: > On Thu, Mar 27, 2014 at 11:03:46AM -0700, Junio C Hamano wrote: > > "Michael S. Tsirkin" writes: > > > > > I started to remove that code, but then I recalled why I did it like > > > this. There is a good reason. Yes, you can't simply reorder hunks just > > > like this. But you can get the same effect by prefixing the header: > > > > Yes, that is one of the things I personally have on the chopping > > block. Having to deal with more than occurrences of the same > > pathname in the input made things in builtin/apply.c unnecessarily > > complex and I do not see a real gain for being able to concatenate > > two patches and feed it into a single "git apply" invocation. > > Well - I expect that this will surprise some people: gnu > patch accepts this, and it's a natural assumption > that it works. There could be tools producing such diffs, too. This behaviour also seems to be explicitly required by POSIX: http://pubs.opengroup.org/onlinepubs/7908799/xcu/patch.html If the patch file contains more than one patch, patch will attempt to apply each of them as if they came from separate patch files. (In this case the name of the patch file must be determinable for each diff listing.) It's better to stick to standards even if it does require a bit more code, isn't it? > Anyway - we can drop this from patch-id and git apply at > the same time? > > -- > MST