On Fri, Mar 28, 2014 at 12:20:13PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Patch id changes if you reorder hunks in a diff.
> > As the result is functionally equivalent, this is surprising to many
> > people.
> > In particular, reordering hunks is helpful to make patches
Junio C Hamano writes:
>> @@ -99,6 +116,18 @@ static int get_one_patchid(unsigned char *next_sha1,
>> git_SHA_CTX *ctx, struct st
>> if (!memcmp(line, "@@ -", 4)) {
>> /* Parse next hunk, but ignore line numbers. */
>>
"Michael S. Tsirkin" writes:
> +static void flush_one_hunk(unsigned char *result, git_SHA_CTX *ctx)
> {
> - int patchlen = 0, found_next = 0;
> + unsigned char hash[20];
> + unsigned short carry = 0;
> + int i;
> +
> + git_SHA1_Final(hash, ctx);
> + git_SHA1_Init(ctx);
>
"Michael S. Tsirkin" writes:
> Patch id changes if you reorder hunks in a diff.
> As the result is functionally equivalent, this is surprising to many
> people.
> In particular, reordering hunks is helpful to make patches
> more readable (e.g. API header diff before implementation diff).
> In git
"Michael S. Tsirkin" writes:
> Patch id changes if you reorder hunks in a diff.
Reording "files" is fine, and as we discussed, having multiple
patches that touch the same path is fine, but do not sound as if you
are allowing to reorder "hunks" inside a single patch that touch a
single file.
Tha
5 matches
Mail list logo
