Re: problem with parsing of patch files for patch-id

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rob Linden <rlinden@xxxxxxxxxx> writes:

>> Rob Linden <rlinden@xxxxxxxxxx> writes:
>>
>> > This patch (also attached) fixes it by only considering commit hashes
>> > in a "From xxxxx..." line:
>>
>> If I am not mistaken, "git patch-id" was designed to read from
>>
>>     git rev-list ... commit range ... | git diff-tree --stdin -p
>>
>> where we see
>>
>>     9005149a4a77e2d3409c6127bf4fd1a0893c3495
>>     diff --git a/path b/path
>>     index ...
>>     ... patch text here ...
>>
>> so I would suspect that limiting the commit object names only to
>> those that follow "From " (i.e. the format-patch output or output
>> with the "--format=email" option) would break existing use cases big
>> time.
> ...
> Hello Junio!
> Thanks for the clue, You're right... I only work with the email format
> so I didn't think of that.
> My solution doesn't work then...
> I had a different idea first: to check if we already got an oid and
> only read a new one once
> the current diff is finished (and wasn't empty so far). The other one
> seemed just simpler.
> I will try again...
> Thanks & all the best,
> rob

Since then I sent a series [*] that was designed to address the
issue you raised here, but unfortunately nobody seems to have paid
attention and the patches are left hanging.  It is part of my 'seen'
branch and in the broken-out format parked on the jc/patch-id branch
in the https://github.com/gitster/git/ repository, ending with the
commit 3226bd87 (patch-id: tighten code to detect the patch header,
2024-06-21).

If you can test (and if possible code review) them, that may help
the series to move forward.

Thanks.



[Reference]

 * https://lore.kernel.org/git/20240621231826.3280338-1-gitster@xxxxxxxxx/




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux