From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id ffc48603 for ; Fri, 29 Nov 2019 20:53:18 +0000 (UTC) Received: (qmail 21419 invoked by alias); 29 Nov 2019 20:53:13 -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: List-Unsubscribe: X-Seq: 44959 Received: (qmail 25699 invoked by uid 1010); 29 Nov 2019 20:53:13 -0000 X-Qmail-Scanner-Diagnostics: from out5-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.0/25642. spamassassin: 3.4.2. Clear:RC:0(66.111.4.29):SA:0(-2.6/5.0):. Processed in 0.733 secs); 29 Nov 2019 20:53:13 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=fm1; bh=WJH1U+9Gy0p6P0NL3BIMp1blM2cHXilaRyi2xora Qx4=; b=rKNW6/Ldu3NypZHx8y/laEsCLFKbpi/fiiDdpvIbgVETzs99BVPwN8eb gY6VZ9qKmOdJPh+UmA581CJKcEuQ3iNRdEQT4StheT/o4Wg1GGOWR+a+k4i0UvCK f3TL1QyT0+9+FXzKkw1noWlqCVL6eLwatyBNU25eQU95Gvn/cGfVNmDb+xtHYgqE pXukEFG9B/zqxbYAOObh2Ihy3ulSQvU/pJ6erdNEbeRM9ikSHXrr0EunFAHaaMFC TMEF3I9sbf8rwZHD+TFqIH1BN429tMB0ziayDsTU7ynhBpXb7SDPWIdwTBetVt74 MbUqWJ1Vh/phSWu/vlU5/0/lENiIiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=WJH1U+9Gy0p6P0NL3BIMp1blM2cHXilaRyi2xoraQ x4=; b=j4lMfoFOX1dAatrVLZ4+EEGGo5jmkVxem1dO6xZ2ialofcQk3EuFrhE1o sxn4r7esDWc9XQCP7VL/PZVckZc+bvbd4mZTgfT224qTGQVkVX5ywD8HACRfyAqs zaY8IVHAVinfvJxyZ9xPKdym8idYWG4l4qSDHadmyP0T4UBVoWJvDfbKCBrJiLWg UP1hbP8Cn4MU2iIL6s8qajq8YNjxBqvkRY30TduUnDa51UdGNa26KxvkdZg9DJod MdHfIry/i0XODECB/nstiz7FdtBd+hmFiI5cUZdGL01gAJu+02g8SdoDmLzNsXSf +BWvOXlVu6EZT5KnaWumDMNf4QqXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeiledgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggugfgjfgesthektddttderudenucfhrhhomhepffgr nhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvg eqnecukfhppeejledrudektddrheejrdduudelnecurfgrrhgrmhepmhgrihhlfhhrohhm pegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvgenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Date: Fri, 29 Nov 2019 20:52:36 +0000 From: Daniel Shahaf To: Aleksandr Mezin Cc: zsh-workers@zsh.org Subject: Re: [PATCH 2/3] vcs_info/cvs: set vcs_comm[basedir] in VCS_INFO_detect_cvs Message-ID: <20191129205236.tt3pmraw2sibqwvu@tarpaulin.shahaf.local2> References: <9438ca11-d0be-4c67-a5b3-a0b900342302@www.fastmail.com> <5edaa985-4ac9-411c-b4c2-415c49a563e3@www.fastmail.com> <20191128213430.53b5akiq43l7bzbx@tarpaulin.shahaf.local2> <20191129203052.fpzwna5jv5i5tqu3@tarpaulin.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191129203052.fpzwna5jv5i5tqu3@tarpaulin.shahaf.local2> User-Agent: NeoMutt/20170113 (1.7.2) Daniel Shahaf wrote on Fri, Nov 29, 2019 at 20:30:52 +0000: > In the meantime, the first two patches in this series can be applied, > can't they? Or were you planning to revise and resubmit the CVS one to > address the (preëxisting) infinite loop? The first two patches should > cause no behaviour change, I assume, other than making $hook_com[basedir] > available to hooks earlier. Actually, should we document $hook_com[basedir] > in the manual? Never mind, I misread the code: it's $vcs_comm[basedir], not $hook_com[basedir]. The former is only used for communicating between a VCS_INFO_detect_${vcs} function that uses VCS_INFO_bydir_detect and the corresponding VCS_INFO_get_data_${vcs} function. Incidentally, VCS_INFO_detect_cvs should probably use VCS_INFO_bydir_detect. Cheers, Daniel