From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 7682C1F4B4 for ; Fri, 16 Oct 2020 20:11:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393562AbgJPULU (ORCPT ); Fri, 16 Oct 2020 16:11:20 -0400 Received: from cloud.peff.net ([104.130.231.41]:34788 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393559AbgJPULU (ORCPT ); Fri, 16 Oct 2020 16:11:20 -0400 Received: (qmail 31622 invoked by uid 109); 16 Oct 2020 20:11:20 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 16 Oct 2020 20:11:20 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 12375 invoked by uid 111); 16 Oct 2020 20:11:19 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Fri, 16 Oct 2020 16:11:19 -0400 Authentication-Results: peff.net; auth=none Date: Fri, 16 Oct 2020 16:11:19 -0400 From: Jeff King To: Junio C Hamano Cc: "Bradley M. Kuhn" , Philippe Blain , Git mailing list Subject: Re: [PATCH 0/1] Clarify and expand description of --signoff Message-ID: <20201016201119.GA3356073@coredump.intra.peff.net> References: <20201015215933.96425-1-bkuhn@sfconservancy.org> <59E3B060-63E3-41C2-A7C4-5B2C888F8D68@gmail.com> <20201016015937.GA3335046@coredump.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Oct 16, 2020 at 12:53:56PM -0700, Junio C Hamano wrote: > > Jeff King writes: > > > >> What should we change there? We could perhaps bring up signoffs earlier > >> or more prominently. Or tie it in to the git-commit docs by saying > >> explicitly: these are _our_ project rules for signoffs. > > Let's tie this loose end. How about squashing in something like > this? Thanks for writing this up. I agree it makes the text much better (not only in emphasizing the point we've been discussing, but also in general clarity). You said "squashing", but I'd suggest keeping it as its own patch on top of Bradley's. -Peff