From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20771 invoked by alias); 30 Oct 2016 07:08:31 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39771 Received: (qmail 9227 invoked from network); 30 Oct 2016 07:08:31 -0000 X-Qmail-Scanner-Diagnostics: from mail-qt0-f172.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.216.172):SA:0(0.0/5.0):. Processed in 0.33511 secs); 30 Oct 2016 07:08:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.216.172 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3R+1wwgJ2psZJ2E4RrnrPe6eFLVvEKVsk60kwGeB0M4=; b=XWGrmb//GCSZnZzGTSv58mRdX21y9YPjiPJI8z8ViK8djfBQ/bwJFfd/4pd1NDbCwu 44n1mBc9LpCzli6K5yzoZ19PGor1TdPF2TBabZgP3tpIB2RHA/Wh6Y7GsvoxrqhTudWH 2Vh+mvbIW7mbRPqQ/5vhZPhLeFWW1uW3k9iYYQCN0RoZb7ttk20u7q9q3Ufo+G6bc+NV TxVEhaA/bHpurXudSpHu09uqJprxaJhzYqMDZclDj228ZLB16EJQVkfFjCQLhHkZUlTk qYZHj4I8L0Vo89ujLO9LFzwCLiCkjVa1AAyO9A1qiqmGOMGu/KbSJR/133SVD7XUexAa fRWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3R+1wwgJ2psZJ2E4RrnrPe6eFLVvEKVsk60kwGeB0M4=; b=lCcGALsZ7vwnnTEqjKmdC204//WIOSYMTb2pLoYbwCxlcU57TlZToqGsX8LbGD90+n odxL8nCcFOOOfzSwWyLFU7Zc56vJ+dzOoULaV9VwAmF+Gqcfic/jE2ONohgDaio07aS8 qQ/TfHhc5kGS8d1z8h82kiFxd4oVH8hxpxzDnW93an1HVfqP4n7S7BVHzOTAmboDrtjU Gd6qJac2GPrhcUtti+1d6YIn0g5yeiOtuPe6VMSNtfG7MG+mnR7fd6jRUH53iHtIbcgQ B0yPb5kigP7XA7hQEP07W981nKcaSIxD7O6FwzotpAUwhaeWvE33v5brQRJMRFOXt/v4 jDCw== X-Gm-Message-State: ABUngvfPciJDr+6qxzwVekFSTrNlq5/m62GFC5217W9RtI4Yy7IWRqllpROC1b/Gk0NiYxw4FvD/Uzr6D6PcIg== X-Received: by 10.237.51.167 with SMTP id v36mr15014952qtd.46.1477810865657; Sun, 30 Oct 2016 00:01:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161030024723.62832-1-john.reed.riley@gmail.com> References: <20161030024723.62832-1-john.reed.riley@gmail.com> From: Mikael Magnusson Date: Sun, 30 Oct 2016 08:01:05 +0100 Message-ID: Subject: Re: [PATCH] Fix hexdump command used for mercurial dirstate parsing To: Reed Riley Cc: zsh workers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 30, 2016 at 3:47 AM, Reed Riley wro= te: > Normally, the old command works. But very rarely, it outputs a string > like the following instead: > =E2=9D=AF hexdump -n20 -e '1/1 "%02x"' .hg/dirstate > 77bba665e970146bd2be0b2da40092e340* > 8804 > > Changing the command resolves the problem: > =E2=9D=AF xxd -p -l20 .hg/dirstate > 77bba665e970146bd2be0b2da40092e340408804 > --- > Functions/VCS_Info/Backends/VCS_INFO_get_data_hg | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg b/Functions= /VCS_Info/Backends/VCS_INFO_get_data_hg > index f35ad59..abcd8bc 100644 > --- a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg > +++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg > @@ -42,7 +42,7 @@ if zstyle -t ":vcs_info:${vcs}:${usercontext}:${rrn}" g= et-revision ; then > if zstyle -t ":vcs_info:${vcs}:${usercontext}:${rrn}" use-simple \ > && ( VCS_INFO_check_com hexdump ) && [[ -r ${dirstatefile} ]= ] ; then > # Calling hexdump is (much) faster than hg but doesn't get the l= ocal rev > - r_csetid=3D$(hexdump -n 20 -e '1/1 "%02x"' ${dirstatefile}) > + r_csetid=3D$(xxd -p -l20 ${dirstatefile}) > else > # Settling for a short (but unique!) hash because getting the fu= ll > # 40-char hash in addition to all the other info we want isn't I don't think it's a good idea to add a dependency on Vim here. --=20 Mikael Magnusson