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-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 616561F910 for ; Sun, 30 Oct 2022 22:02:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229645AbiJ3WBv (ORCPT ); Sun, 30 Oct 2022 18:01:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229597AbiJ3WBu (ORCPT ); Sun, 30 Oct 2022 18:01:50 -0400 Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 255986171 for ; Sun, 30 Oct 2022 15:01:49 -0700 (PDT) Received: from 88-110-102-84.dynamic.dsl.as9105.com ([88.110.102.84] helo=[192.168.1.57]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1opGNH-0004Js-DL; Sun, 30 Oct 2022 22:01:47 +0000 Message-ID: <85f56b56-74c5-ffe5-703f-ef0c1e6d3b45@iee.email> Date: Sun, 30 Oct 2022 22:01:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options Content-Language: en-GB To: Taylor Blau Cc: GitList , Junio C Hamano , NSENGIYUMVA WILBERFORCE References: <20221030185614.3842-1-philipoakley@iee.email> <20221030185614.3842-2-philipoakley@iee.email> From: Philip Oakley In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 30/10/2022 19:23, Taylor Blau wrote: > On Sun, Oct 30, 2022 at 06:56:14PM +0000, Philip Oakley wrote: >> Instead of replacing with "..", replace with the empty string "", >> having adjusted the padding length calculation. >> >> Needswork: >> There are no tests for these pretty formats, before or after >> this change. > Hmmph. I see some when searching for l?trunc in > t4205-log-pretty-formats.sh. Is that coverage not sufficient for the > existing feature? > > If so, it would be nice to see it bulked up to add coverage where we > are missing some. Either way, we should make sure the new code is > covered before continuing. No idea how I missed them. Maybe I'd filtered, by accident, the search by a too narrow list of file types. Thanks for that pointer. >> @@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */ >> padding - 2, len - (padding - 2), >> ".."); >> break; >> + case trunc_left_hard: >> + strbuf_utf8_replace(&local_sb, >> + 0, len - (padding), >> + ""); >> + break; >> + case trunc_right_hard: >> + strbuf_utf8_replace(&local_sb, >> + padding, len - (padding), >> + ""); >> + break; > If I remember correctly, strbuf_utf8_replace() supports taking NULL as > its last argument, though upon searching I couldn't find any callers > that behave that way. Can we use that instead of supplying the empty > string? If not, should we drop support for the NULL-as-last-argument? I wasalso  concerned about zero length strings but my brief look at the code indicated it could cope with a zero length string. The last param is `const char *subst`. I've just relooked at the code and it does have a      if (subst)         subst_len = strlen(subst); so it does look safe to pass NULL, though it would probably cause a pause for thought for readers, and isn't likely to be that much faster in these format scenarios. > > Thanks, > Taylor -- Philip