git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/5] patch-id: tighten code to detect the patch header
Date: Mon, 29 Jul 2024 13:12:42 -0700	[thread overview]
Message-ID: <xmqqwml4gdol.fsf@gitster.g> (raw)
In-Reply-To: <ZqeGBJrqIrU2A4jl@tanuki> (Patrick Steinhardt's message of "Mon, 29 Jul 2024 14:07:32 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> On Fri, Jun 21, 2024 at 04:18:26PM -0700, Junio C Hamano wrote:
>> @@ -196,11 +211,13 @@ static void generate_id_list(unsigned flags)
>>  	struct strbuf line_buf = STRBUF_INIT;
>>  
>>  	oidclr(&oid);
>> +	flags |= GOPID_FIND_HEADER;
>>  	while (!feof(stdin)) {
>>  		patchlen = get_one_patchid(&n, &result, &line_buf, flags);
>>  		if (patchlen)
>>  			flush_current_id(&oid, &result);
>>  		oidcpy(&oid, &n);
>> +		flags &= ~GOPID_FIND_HEADER;
>>  	}
>
> I think I'm missing the obvious. But why don't we have to set
> `GOPID_FIND_HEADER` when we have flushed the current patch ID? Is this
> because we know that `get_one_patchid()` stops once it finds the next
> line starting with a commit?

Yup the original control flow is rather convoluted.  The first call
stops when it finds the header that begins the log message part and
returns, but the subsequent calls are to (1) skip the log message
and then (2) parse and hash the diff part, until it finds another
header that begins the log message part of the _next_ patch and
return.  GOPID_FIND_HEADER bit is used to tell the callee when we
haven't found the header (hence we can stop at a line whose
beginning looks like a hash) or the previous round already found the
header and we positively know we are now in the "skip the log
message" phase (hence a line whose beginning looks like a hash is
not a new header).

> Makes me wonder what happens when there is
> non-diff garbage between patches for which we are about to generate
> patch IDs.

"Skip non-diff garbage until we see a patch" is the mechanism used
to skip the log message, so it would be a reasonable thing to skip
such no-diff garbage between patches, no?

  reply	other threads:[~2024-07-29 20:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 23:18 [PATCH 0/5] Tighten patch header parsing in patch-id Junio C Hamano
2024-06-21 23:18 ` [PATCH 1/5] t4204: patch-id supports various input format Junio C Hamano
2024-06-21 23:18 ` [PATCH 2/5] patch-id: call flush_current_id() only when needed Junio C Hamano
2024-06-21 23:18 ` [PATCH 3/5] patch-id: make get_one_patchid() more extensible Junio C Hamano
2024-07-29 12:02   ` Patrick Steinhardt
2024-07-29 20:03     ` Junio C Hamano
2024-06-21 23:18 ` [PATCH 4/5] patch-id: rewrite code that detects the beginning of a patch Junio C Hamano
2024-07-29 12:03   ` Patrick Steinhardt
2024-06-21 23:18 ` [PATCH 5/5] patch-id: tighten code to detect the patch header Junio C Hamano
2024-07-29 12:07   ` Patrick Steinhardt
2024-07-29 20:12     ` Junio C Hamano [this message]
2024-07-30  4:55       ` Patrick Steinhardt
2024-07-30  5:12         ` Patrick Steinhardt
2024-07-30  1:17 ` [PATCH v2 0/5] Tighten patch header parsing in patch-id Junio C Hamano
2024-07-30  1:17   ` [PATCH v2 1/5] t4204: patch-id supports various input format Junio C Hamano
2024-07-30  1:17   ` [PATCH v2 2/5] patch-id: call flush_current_id() only when needed Junio C Hamano
2024-07-30  1:17   ` [PATCH v2 3/5] patch-id: make get_one_patchid() more extensible Junio C Hamano
2024-07-30  1:17   ` [PATCH v2 4/5] patch-id: rewrite code that detects the beginning of a patch Junio C Hamano
2024-07-30  1:17   ` [PATCH v2 5/5] patch-id: tighten code to detect the patch header Junio C Hamano
2024-07-30  5:12   ` [PATCH v2 0/5] Tighten patch header parsing in patch-id Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqwml4gdol.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).