From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server-vie001.gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=new2025; t=1754399093; bh=0b7AAFqk+TiUHU/xpy55QQzq9/zthLuGbHVscN+Vamk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To:Message-ID:Date:From:Reply-To:Subject:To: Cc:In-Reply-To:References:Resent-Date:Resent-From:Resent-To: Resent-Cc:User-Agent:Content-Type:Content-Transfer-Encoding; b=a0IvVJ0u3iBlORbANAmG3QYVAtvO7SK8hYwmKt7taIQZwwuHkgfH+uOimHdmbOn/u fBgFykH88s9CSqX1bn8BburWIEj7dczvdhDNAENvO+o3JRZpiidtibSpKpFbUSeW+1 GYwi0zBBV+LOuVs1NkJqnHMhYrdxmBGo+BXDvyi9eyEBxP6qEYhItqHel9tmlhNDYy 7VPboINNok7/6lP38/LCtmOjQ5iRVXqpEly9rWvSH7wQAD2TeeMi1ePCw86ubl88Rz EcnryBFDFiR+QGoV58Qr6dvpHoAVdsu0IODB4l87oFMGvaHHBKQneK0vm5NggnBFlG YOhTE34X66KCw== Received: from biznet-home.integral.gnuweeb.org (unknown [182.253.126.229]) by server-vie001.gnuweeb.org (Postfix) with ESMTPSA id 3144B312805B; Tue, 5 Aug 2025 13:04:52 +0000 (UTC) Date: Tue, 5 Aug 2025 22:04:48 +0900 From: Ammar Faizi To: Ahmad Gani Cc: Alviro Iskandar Setiawan , GNU/Weeb Mailing List Subject: Re: [PATCH gwproxy v3 6/9] dnsparser: Fix serialize_answ function Message-ID: References: <20250805064933.109080-1-reyuki@gnuweeb.org> <20250805064933.109080-7-reyuki@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: On Tue, Aug 05, 2025 at 07:47:38PM +0700, Ahmad Gani wrote: > By the way, I have another question. If a patch appears to be bug-free and > gets applied but later turns out to have a bug, will the fix be included in > the problematic commit found by git bisect or added as a new commit that > refers to the original one? I assume the latter makes more sense, since > it preserves the commit history for other contributors. If the patch has been applied, it's already set in stone and should not be rebased because someone else might have pulled it (which will break the hash chain in the git history, just like a blockchain, it's immutable once it's distributed all over the world). The fix should be submitted as a new patch with a Fixes tag with at least the first 12 chars of the first SHA1 commit hash and followed by its full subject line. For example: https://patchwork.kernel.org/project/netdevbpf/patch/20250801190310.58443-1-ammarfaizi2@gnuweeb.org/ -- Ammar Faizi