linux-kernel - Re: linux-next: manual merge of the jc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87o70kt232.fsf@trenco.lwn.net>
Date: Mon, 06 Jan 2025 08:05:21 -0700
From: Jonathan Corbet <corbet@....net>
To: Stephen Rothwell <sfr@...b.auug.org.au>, Andrew Morton
 <akpm@...ux-foundation.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>, Linux Kernel Mailing List
 <linux-kernel@...r.kernel.org>, Linux Next Mailing List
 <linux-next@...r.kernel.org>, Tamir Duberstein <tamird@...il.com>
Subject: Re: linux-next: manual merge of the jc_docs tree with the mm tree

Stephen Rothwell <sfr@...b.auug.org.au> writes:

> Hi all,
>
> Today's linux-next merge of the jc_docs tree got a conflict in:
>
>   scripts/checkpatch.pl
>
> between commit:
>
>   253f01394dc0 ("checkpatch: check return of `git_commit_info`")
>
> from the mm-nonmm-unstable branch of the mm tree and commit:
>
>   6356f18f09dc ("Align git commit ID abbreviation guidelines and checks")
>
> from the jc_docs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix looks fine, but...

> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc scripts/checkpatch.pl
> index 744328d21eb8,f7087dda9ac9..000000000000
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@@ -3237,12 -3237,12 +3237,12 @@@ sub process 
>   			my ($cid, $ctitle) = git_commit_info($orig_commit, $id,
>   							     $title);
>   
>  -			if ($ctitle ne $title || $tag_case || $tag_space ||
>  -			    $id_length || $id_case || !$title_has_quotes) {
>  +			if (defined($cid) && ($ctitle ne $title || $tag_case || $tag_space || $id_length || $id_case || !$title_has_quotes)) {
>  +				my $fixed = "Fixes: $cid (\"$ctitle\")";
>   				if (WARN("BAD_FIXES_TAG",
> - 				     "Please use correct Fixes: style 'Fixes: <12 chars of sha1> (\"<title line>\")' - ie: '$fixed'\n" . $herecurr) &&
>  -				     "Please use correct Fixes: style 'Fixes: <12+ chars of sha1> (\"<title line>\")' - ie: 'Fixes: $cid (\"$ctitle\")'\n" . $herecurr) &&
> ++				     "Please use correct Fixes: style 'Fixes: <12+ chars of sha1> (\"<title line>\")' - ie: '$fixed'\n" . $herecurr) &&

...it all comes down to a single "+" sign here.  If 253f01394dc0 could
be tweaked to add that character, I think this conflict would go away
and we wouldn't make Linus delve into Perl code...?

Just a thought.

Thanks,

jon