From patchwork Thu Dec 22 20:16:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Wong X-Patchwork-Id: 13080289 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42659C4332F for ; Thu, 22 Dec 2022 20:16:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230248AbiLVUQY (ORCPT ); Thu, 22 Dec 2022 15:16:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbiLVUQW (ORCPT ); Thu, 22 Dec 2022 15:16:22 -0500 Received: from dcvr.yhbt.net (dcvr.yhbt.net [173.255.242.215]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC92CFD06 for ; Thu, 22 Dec 2022 12:16:19 -0800 (PST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 839231F852; Thu, 22 Dec 2022 20:16:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org; s=selector1; t=1671740179; bh=gr8/XXou85fa4ohfJU2rTZkSXVHxGURLV5Fi2xeCJJ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rmZK0aK5LQQ5IDVx0SxkLF/HmEdkqoTbthTKcw7ke+15ZtQ25KDWYOmn/aUYp2AyG UGSE4JcQjYObdoywQ9AZhBa7leW7pMIQaIpFHCKybE4HCRv3UQ++lF9gql2mxBVxzm ZGqEO6//gcNim60jzj4Lior+P8EyiveCaCk4mz00= Date: Thu, 22 Dec 2022 20:16:19 +0000 From: Eric Wong To: Junio C Hamano Cc: =?utf-8?b?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , git@vger.kernel.org Subject: [PATCH v2] format-patch: support format.mboxrd with --stdout Message-ID: <20221222201619.M435985@dcvr> References: <20221114094114.18986-1-e@80x24.org> <221114.86leodlbix.gmgdl@evledraar.gmail.com> <20221114205909.GA14736@dcvr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano wrote: > Eric Wong writes: > >> > + if (mboxrd) > >> > + rev.commit_format = CMIT_FMT_MBOXRD; > >> > + > > > > It could be something like this: > > > > if (rev.commit_format == CMIT_FMT_MBOXRD && !use_stdout) > > warning("mboxrd without --stdout makes no sense\n"); > > > > But I'm on the fence about the warning. OK, so the warning won't be necessary if using format.mboxrd via config. > Does it really hurt when generating individual files, or does it > naturally degenerate to the same as the plain old mbox, or > something? If it does not hurt, then let's not clutter the output > with a message that may make the user worried unnecessarily. mboxrd is bad for individual files since it can leave '>From' escaping if applied w/o `--patch-format mboxrd". My revised patch only enables mboxrd if --stdout is in use. > Having said all that, if --pretty=mboxrd is usable, do we really > need the --mboxrd short-hand? If we plan to eventually switch the > default output format to mboxrd (which I am assuming your longer > term vision), wouldn't it be the traditional format that may need a > short-hand when something goes wrong? Actually, I never considered making mboxrd a config file knob. But yes, it seems like a good idea. I hadn't considered making it the default, actually. The current `--pretty=email --stdout' is probably "good enough" for many users since the "From "-splitting in mailsplit is strict and legitimate commit messages are unlikely to have splittable "From " lines. > This change does not seem to be something we cannot live without, That double negative confused me :x "This change seems to be something we can live without" Yes, I agree. > and as a step in the direction to move all of us to mboxrd, this > feels somewhat a roundabout step. I wonder if it would be more > direct to > > - declare that we will eventually switch to use mboxrd by default; > > - give a configuration knob to retain the current email as default; > > - do the usual deprecation dance. I don't know if changing the default+deprecation is necessary, but thanks for suggesting a config knob. > After all, between email and mboxrd, the e-mailed patch format is > not something we choose per-invocation basis, is it? Right. > Picking a suitable format per project and setting it in .git/config, > or picking a suitble format for yourself and setting it in > ~/.gitconfig, and not having to think about it afterwards may be a > better use of our users' time. Agreed. Thanks for the suggestions. ------------8<------------- Subject: [PATCH v2] format-patch: support format.mboxrd with --stdout mboxrd is a more robust output format when used with --stdout and needs more exposure. Introducing this config knob lets users choose the more robust format for all their --stdout uses. Relying on --pretty=mboxrd and including all of pretty-formats.txt in the `git format-patch' documentation would likely be confusing to users. Furthermore, this setting is useful across multiple invocations. So introduce `format.mboxrd' as a boolean configuration knob that changes the default --pretty=email format to --pretty=mboxrd when (and only when) --stdout is in use. Signed-off-by: Eric Wong --- Interdiff: diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt index c7303d8d9f..3bd78269e2 100644 --- a/Documentation/config/format.txt +++ b/Documentation/config/format.txt @@ -139,3 +139,7 @@ For example, ------------ + will only show notes from `refs/notes/bar`. + +format.mboxrd:: + A boolean value which enables the robust "mboxrd" format when + `--stdout` is in use to escape "^>+From " lines. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index b080d3c61e..dfcc7da4c2 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e-mail submission SYNOPSIS -------- [verse] -'git format-patch' [-k] [(-o|--output-directory) | --stdout] [--mboxrd] +'git format-patch' [-k] [(-o|--output-directory) | --stdout] [--no-thread | --thread[=