Re: [PATCH 1/3] patch-id: make it stable against hunk reordering
- From
- Michael S. Tsirkin <mst@redhat.com>
- Date
- Mar 27, 2014, 18:45 UTC
- Message-ID
- <20140327184515.GA4056@redhat.com>
- In-Reply-To
- <20140327183917.GA3980@redhat.com>
On Thu, Mar 27, 2014 at 08:39:17PM +0200, Michael S. Tsirkin wrote:
Show 16 quoted lines
> On Thu, Mar 27, 2014 at 11:03:46AM -0700, Junio C Hamano wrote: > > "Michael S. Tsirkin" <mst@redhat.com> 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?
Show 5 quoted lines
> Anyway - we can drop this from patch-id and git apply at > the same time? > > -- > MST