From owner-freebsd-git@freebsd.org Wed Dec 16 10:23:54 2020 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D15124B7CB8 for ; Wed, 16 Dec 2020 10:23:54 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cwrnk5VpMz4jZt for ; Wed, 16 Dec 2020 10:23:54 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BCF0E4B7E85; Wed, 16 Dec 2020 10:23:54 +0000 (UTC) Delivered-To: git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BCB954B787A for ; Wed, 16 Dec 2020 10:23:54 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cwrnk4ycmz4jm3; Wed, 16 Dec 2020 10:23:54 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: lwhsu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 983176F4B; Wed, 16 Dec 2020 10:23:54 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mail-yb1-f174.google.com with SMTP id w139so21906916ybe.4; Wed, 16 Dec 2020 02:23:54 -0800 (PST) X-Gm-Message-State: AOAM532deskVUNc8uZhZRgLKHobi+wt8D7ZqJGQmyM88cZcJG/qf9KxC Jl2AL/MUCIzwZwX7Utt7eagaVHJcXjra+K7jIEQ= X-Google-Smtp-Source: ABdhPJwBlQTD8FkuZUwBYDm1ljdX78yySlbcEd3+yONu7YInvwxspG8Mtqwk6QR0r0sQn55yOEf81bkBx/7SH3H66i8= X-Received: by 2002:a25:3206:: with SMTP id y6mr49500971yby.127.1608114233791; Wed, 16 Dec 2020 02:23:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Li-Wen Hsu Date: Wed, 16 Dec 2020 18:23:42 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Thoughts on git commit mail To: John Baldwin Cc: git@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 10:23:54 -0000 On Wed, Dec 16, 2020 at 7:59 AM John Baldwin wrote: > > So far I have a few possible suggestions on the git commit mail > that I would find useful. Mostly it consists of making it a bit > leaner: Thanks for the inputs and I'll try to squeeze time to implement them, and/or find a suitable place to put the insensitive config files and scripts for let more people to join the development. > 1) I would only display Author/AuthorDate. The committer we can > infer from the e-mail sender. This is what the gdb git commit > mails do. In this case you can also just use 'Date' instead > of AuthorDate, e.g.: > > commit d79b57d3cf7151e45216c0f8501cdb2eb7a3bd86 > Author: Glen Barber > AuthorDate: 2020-12-13 21:31:39 +0000 > Commit: Glen Barber > CommitDate: 2020-12-13 21:31:39 +0000 > > could become: > > commit d79b57d3cf7151e45216c0f8501cdb2eb7a3bd86 > Author: Glen Barber > Date: 2020-12-13 21:31:39 +0000 > > 2) I would drop the first sentence. It's a bit redundant to list > the committer an extra time. The branch name is useful, but it > might be nicer as metadata if possible, e.g.: > > Branch: main > > The one thing this does lose is when a commit is a "cross-repo" > commit (e.g. docs committer committing to src or vice versa). > The best way to handle this might be to add a new optional > metadata field. I don't have any good ideas on what to call > it. It could either list the repositories a committer has a > bit for, or it could just be some kind of boolean > (Cross-Commit: yes). > > 3) Perhaps put the URL in the metadata section as well to reduce > extra blank lines at the start of the mail. > > Putting 1-3 together for the commit in question would give the > header below which I think is a bit more compact and similar to > svn formatting in that all the metadata is in a single block > without additional whitespace. > > commit d79b57d3cf7151e45216c0f8501cdb2eb7a3bd86 > Author: Glen Barber > Date: 2020-12-13 21:31:39 +0000 > Branch: main > URL: https://cgit.FreeBSD.org/doc/commit/?id=d79b57d3cf7151e45216c0f8501cdb2eb7a3bd86 This sounds good to me, the reason I have both Author and Committer fields because I was thinking if we have pull request / merge workflow, there will be more commits and pushes with different author/committer/pusher, and the date of these three will be different, the From and Date fields in mail header can only cover the pusher. BTW, the current commit hook does check all the commits in a push and verify all the committer fields are the same with pusher, so the above issue might not happen. I was just preserving some flexibility. > 4) Some repository-specific things I would find helpful based on how > I have filtered svn commits: > > - For doc, some kind of mail header ('X-Git-Foo') to indicate commits that > only touch translations as separate from English and top-level shared > areas. Previously I used some pattern matches on paths in svn subjects > to do this. > > - For src, some kind of mail header to indicate commits that touch the > kernel vs only touching userland. I don't quite get these, can you provide some examples to help me understand them thoroughly? Do you mean we can have something like we have in svn, there are the paths (directories) touched in the subject and headers? This was not implemented when the doc migration due to the time constraint, but I'll look into them after the higher priority items in the migration are done. Best, Li-Wen