Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp152234pxj; Thu, 3 Jun 2021 03:19:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkU3bwdiSw98SA/T6h/IEudZIOsqn4bjxqjkgS5saCzuH1OAhgd7LS7o8rq1LCi05fPF0k X-Received: by 2002:a05:6402:1a:: with SMTP id d26mr44349247edu.105.1622715595982; Thu, 03 Jun 2021 03:19:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622715595; cv=none; d=google.com; s=arc-20160816; b=G2DnBIbB8Wby/w/UmV3EQR4vTZfTyl1GzO3VV/yyyW1yYSZDj3kTcDIE0gzgvXusuX 1JuYmFlilgTJUVC++8ye/KJ6IsQiEVWZpNzQu5OKuyks4tVldiI+YnD6WkblWH/+NLBJ twXLWxjIMSgm4MtlhQ33VG2h4yC2B+RrGypNcP1ZYhjJUZOmIz0U87oKL1eeS4ynH/sv vbVvmuvtcgeYmZDkNJvUMfbde7Flgczrj4+yvSie0b0Jcs8vv/2ALrpsQJPmVB4rQyIs kBzseWMaK51i+eTZbS4U80/I+lPvIXdTdF+2qhO1DuIXDU6SKewhTsNm48L4uT4+5GZq 0dew== 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=s2dYAEKF3sS13bEvDeeDpxNGlMMkDWtT4qYijuEzx0g=; b=h/bUxFF8ncjg46ptN6mjIsoKdjuAsGtFkkOwnlNlP48X3ZGJ/pa7OYrNNCgw2ovOV9 HbJy/v3tyQs2OCqem9qh/IKcztwN5hfdB9mPs8bywrkHgh4nyVyhZc33LfGjaAS6kk0p BlH3YmBzGqNTFFOlKvUc8AWG2r/QYNy8b61Gc3KZLAstcSRkilKaAI6qB1mM25A/+I4a qaNzalhz1mUL+kOrVn/Sy+BE8LjCnEsA0etHFdsz7dQTqruugQhnkYufw/wjtrJv0l+e iv22zlyu1LFZIDvcafsHF8k+gcqH4jGdDZEiwyTDFi3NeqElumg+wizqh2dWBkobnMXi jYdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=PW9nAJvk; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=t3CvZQ9O; 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 h3si2071344edw.187.2021.06.03.03.19.31; Thu, 03 Jun 2021 03:19:55 -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=PW9nAJvk; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=t3CvZQ9O; 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 S230074AbhFCKST (ORCPT + 99 others); Thu, 3 Jun 2021 06:18:19 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:49310 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230019AbhFCKSR (ORCPT ); Thu, 3 Jun 2021 06:18:17 -0400 Received: from relay2.suse.de (unknown [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id E994F219B8; Thu, 3 Jun 2021 10:16:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1622715391; 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=s2dYAEKF3sS13bEvDeeDpxNGlMMkDWtT4qYijuEzx0g=; b=PW9nAJvkvO1KE0428ou0opl/nhtgeiZ0V9lsxjb51H7EWs9WycMoxg0q2GqK9dWHCSlynK nKjNYuYqJfC0ag2pb1JyEqx1hPNsjYDEJ3YKUBeO8Kj5PNbn5zgf89Zoga8O4gUy1Exth4 Vd/fQID4dbc9CnA2XSt5bXGM5cfda88= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1622715391; 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=s2dYAEKF3sS13bEvDeeDpxNGlMMkDWtT4qYijuEzx0g=; b=t3CvZQ9OQMOUOKQ4oSM+hp3r0UBcIqAskoHDlrHbqmbPeoyerxQu0gwk58nLbVSIH2TSuE h0f8L2uLoTgk44Dw== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id D2520A3B8A; Thu, 3 Jun 2021 10:16:31 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id E0ECFDA734; Thu, 3 Jun 2021 12:13:50 +0200 (CEST) Date: Thu, 3 Jun 2021 12:13:50 +0200 From: David Sterba To: Al Viro Cc: Mathieu Desnoyers , 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: <20210603101350.GW31483@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Al Viro , 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: 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 03:29:44PM +0000, Al Viro wrote: > On Wed, Jun 02, 2021 at 11:20:35AM -0400, Mathieu Desnoyers wrote: > > Hi, > > > > 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. > > > > Thoughts ? > > Just an observation: quite a few subtle bugs arise from mistakes in > what should've been a trivial cleanup. I was about to write such comment. Cleanups that are eg. mechanically switching names/types/variables/... and need some manual fixup are hot candidates for buggy patches.