Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp157416pxj; Thu, 3 Jun 2021 03:29:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzua6ON7OGudRibAI7cj85gSleNfr/g4Wz+kIK1XfqDjV7jiUkBiC15WSZeyYVE8+/zqt9/ X-Received: by 2002:a17:906:5d14:: with SMTP id g20mr16283994ejt.243.1622716179685; Thu, 03 Jun 2021 03:29:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622716179; cv=none; d=google.com; s=arc-20160816; b=qVJu4P3tmHrmL8uh5YCpS25DqhgH+tZA3psnUlLmKyBWtk9gdMpAsoidMuyRAHGMBi byZoVtC9s2lpMy3tZQ0NtfSZMYTO2zQSW+ivoILGbwPUFtgPmNp5eYWo13viNak4ZZ+p kbbZHv3v9J14QdE+NIBgUdBTFXemaKwUm4nNyazTk3SN1OqHDfIMrTybSKf6tZxxTMMi COxuhKLaUwcGe7wz8frYTw95bf31TXcK4oFCigN90vDP76hU3qN2xt+CRyjBmn3md7vj 5aNQIi6LQmiS6sgw9yarKD+eBccyCCRfBjhU9vQOXLpFmhxiKproixr36THrTOeUdpw6 eBYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=cZJBCRtT1ELw6dkTzAbcE6+F5s7IW/n8Eb6llqxk028=; b=Ll904C0syMEVi+XwF5MuSqDFdZirSys/Gw3SSR56Jv0kEGMkF74EmV8KezX8+CkDTw KBw4YEtZaduV0WfsrheC/rs9J2Pb/32Ay30TViKUji4vmCfJFngiRssJ8uUzRru9kyoI gl863lOjhsnhVQgKfkSoYbdBEYsjHzBNT/puS9J/FFMoPcU2ZPXTv/j8gCuMKR37uvZF wPOMjoNolEi0t8wbLykFu70aOVRSW6NtuzQNX81IJqnP3YQeNfNHvMU2ilz9uglGdGhg 8/n3tb9v/WFKBNoQkKRWFWWKgRK2e8q1kwkO1QfNAb+3G6XplqL5IKfih6+p1SJg2WJ3 DaoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=YTwAYVBj; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=WLafq4mr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f1si1872782ejh.93.2021.06.03.03.28.52; Thu, 03 Jun 2021 03:29:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=YTwAYVBj; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=WLafq4mr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229752AbhFCK13 (ORCPT + 99 others); Thu, 3 Jun 2021 06:27:29 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50020 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229610AbhFCK13 (ORCPT ); Thu, 3 Jun 2021 06:27:29 -0400 Received: from relay2.suse.de (unknown [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 26CC4219D7; Thu, 3 Jun 2021 10:25:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1622715944; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cZJBCRtT1ELw6dkTzAbcE6+F5s7IW/n8Eb6llqxk028=; b=YTwAYVBjW50Aj5sXbmFNJwKRISGcXcsnTwGmQzxCX8Zb9VNGkffyLae+TFNSsyiWa6UL4/ x+RLoz/viKT5pLqqvaSOt4Z2VjPgXkscYiUX0/0aRxLMteR+Z30RKtmb6FNInd8QDfJk6c JR88C57Tx8L92I3I7F4RgZWTTd0p/U8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1622715944; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cZJBCRtT1ELw6dkTzAbcE6+F5s7IW/n8Eb6llqxk028=; b=WLafq4mrilE0X6kdHPDQ9nakrEN9DI1cxjIYfKBLcx4OMFFzQGCOi7Xu0x+6awyHWcpRn2 XqHV8t+mRDDkM8Ag== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 18FA5A3B91; Thu, 3 Jun 2021 10:25:44 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 408C6DA734; Thu, 3 Jun 2021 12:23:03 +0200 (CEST) Date: Thu, 3 Jun 2021 12:23:03 +0200 From: David Sterba To: Mathieu Desnoyers Cc: git@vger.kernel.org, Peter Zijlstra , Thomas Gleixner , linux-kernel , Jiri Kosina , Greg Kroah-Hartman Subject: Re: git feature request: git blame --ignore-cleanup/--ignore-trivial Message-ID: <20210603102303.GX31483@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Mathieu Desnoyers , git@vger.kernel.org, Peter Zijlstra , Thomas Gleixner , linux-kernel , Jiri Kosina , Greg Kroah-Hartman References: <30399052.5964.1622647235870.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30399052.5964.1622647235870.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 02, 2021 at 11:20:35AM -0400, Mathieu Desnoyers wrote: > Following a discussion with Peter Zijlstra about whether code cleanup > and functional changes done to the Linux kernel scheduler belong to separate > patches or should be folded together, the argument for folding cleanup > and function changes came to be mainly motivated by the current behavior > of git blame: code cleanup patches end up burying the important changes so > it becomes cumbersome to find them using git blame. > > Considering the added value brought by splitting cleanups from functional changes > from a maintainer perspective (easier reverts) and from a reviewer perspective > (easier to focus on the functional changes), I think it would be good to improve > the git tooling to allow easily filtering out the noise from git blame. > > Perhaps a new git blame "--ignore-trivial" and/or "--ignore-cleanup" could solve > this by filtering out "trivial" and "cleanup" patches from the history it considers. > > Tagging patches as trivial and cleanup should be done in the patch commit message > (possibly in the title), and enforcing proper tagging of commits is already the > responsibility of the maintainer merging those cleanup/trivial commits into the > Linux kernel anyway. > > Under the hood, I suspect it could use something similar to git log --grep= > --invert-grep. > > This should allow git blame users to easily filter out the noise and focus on the relevant > functional changes. > > Any maybe the patterns associated to "cleanup" and "trivial" commits should be something > that can be configured through a git config file. As long as the subsystem policy is consistent, eg. always split cleanups from functional changes, and make the trivial cleanups really obvious either from code or mentioned in the changelog, I don't see a need for a tooling. Going through unrelated cleanups when digging in the git history is annoying and I think it's up to maintainers' and developers' decision what kind of cleanups are desired (because they make the code better, not just because they're trivial). Mandating some sort of tagging is just another burden, if it's not applied consistently it won't be reliable so it won't help much.