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 ed34e5a8 for ; Mon, 25 Nov 2019 18:23:08 +0000 (UTC) Received: (qmail 23945 invoked by alias); 25 Nov 2019 18:23:01 -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: 44936 Received: (qmail 29777 invoked by uid 1010); 25 Nov 2019 18:23:00 -0000 X-Qmail-Scanner-Diagnostics: from out3-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.27):SA:0(-2.6/5.0):. Processed in 5.091059 secs); 25 Nov 2019 18:23:00 -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=dwDRT1rxjUEJdYEA4R51LlO+TGgftZKMMCywF5Bt muk=; b=GwYcvFlYLLmVhug/5vffsqcrSPIQ65WTewtQBvWR+6ncRbUXixI78Nw9 ysJMCzHdwWfHlUgCiCsTZo+yWL9T2P/cxdYNZm5zH0TEs7P1tkhBZzw1r0+g/v0v +w3Ykv0bV2RvqCu/WNyxtO5oB1n8/U6lEPsnBFmNC6jC/DpbYAgqTFOl1yVXYIqV okFySSl+208uUQfquizhawyY0o/MdWIhCFCMmS41ustTZ5GYeasArJNV+iVj9Ncj qSYsZjmhv+K+nY4893blnknJXm7ACMuIChZ0cHEGMVmOtlox4Jp37UzrmHorUa1g Ffk0DT2+J22NcQOQcsxlXQPd7/0T8A== 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=dwDRT1rxjUEJdYEA4R51LlO+TGgftZKMMCywF5Btm uk=; b=rVihYF+ewQZ8E33lUCSzkntKnUesHVOvD8f04yJzkU+hsxZ6IDjyy5I9X 87iAE4ZTtok2ErzzP/v9WF+Ww27AW+3jm+lD7vXWXixiB3FPUjKPe72OfLdt2k2F s/jdZ3fW966uQkJcl3zjQc+uNvgrquwwBwqKIEEkVUoX2YbYk4Y1ZRcX98QrB2Zu bhp5rYsP2hlhRvSiqvZVuJyoSVLnpTShCUyGI5kWUDgB9hYGfvxKhHWVkQpRJUwm 6I8zBALivMpIL1yJGvidIHhkxq4qeiu5E4hVRtreECroSS+/mOwUVKxhKMDV6UTG PJtL1S/jXNzsXQAdIXYqnJr2G8dxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeiuddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggugfgjfgesthektddttderjeenucfhrhhomhepffgr nhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvg eqnecukfhppeejledrudektddrheejrdduudelnecurfgrrhgrmhepmhgrihhlfhhrohhm pegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvgenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Date: Mon, 25 Nov 2019 18:22:16 +0000 From: Daniel Shahaf To: Zsh hackers list Cc: Aleksandr Mezin Subject: Re: [PATCH 2/3] vcs_info/cvs: set vcs_comm[basedir] in VCS_INFO_detect_cvs Message-ID: <20191125182216.qurp3zdwsmv6i5md@tarpaulin.shahaf.local2> References: <20191123221443.279556-1-mezin.alexander@gmail.com> <20191123221443.279556-3-mezin.alexander@gmail.com> <20191125043525.lcxm532gi6hb7n53@tarpaulin.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Bart Schaefer wrote on Mon, Nov 25, 2019 at 01:13:21 -0800: > I have several directories that are BOTH git and CVS repositories, used for > keeping two different origins in sync. > > This is admittedly an unusual situation -- we have a legacy process that > expects to fetch sources from CVS, and developers collaborating through git > -- but I would be annoyed if vcs didn't find the git data because of the > CVS subdir. Doesn't my proposal address this? In my proposal, if {foo,foo/bar,foo/bar/baz}/CVS and foo/bar/.git all exist, and cwd is foo/bar/baz/, git info would be shown because the git root, foo/bar/, is closer (deeper) than the CVS root, foo/ — notwithstanding that foo/bar/baz/CVS exists. To be self-contained, what I proposed is: - If [[ ${basedirA:P} == ${basedirB:P}/* ]], show ${basedirA}'s info. - If [[ ${basedirB:P} == ${basedirA:P}/* ]], show ${basedirB}'s info. - Show the info for whichever VCS is listed first in the 'enable' style. Would that DTRT in your use-case? > I would expect the list of repo types in the "enable" style to be handled > in the order they appear. Do you mean, that if the enable style lists "git" ahead of "cvs", then vcs_info would always look for git info first and only show CVS info if git wasn't detected? If so, see above. Or do you mean, show _both_ the CVS and git info? I don't see how that would work. Consider: zstyle ':vcs_info:git:default:*' formats foo1 zstyle ':vcs_info:git:default:lorem' formats foo2 bar2 zstyle ':vcs_info:cvs:default:*' formats baz precmd() { vcs_info default; [[ -z $vcs_info_msg_1_ ]] && print -Pr -- $vcs_info_msg_1_ } Would this print "bar2" or "baz"? How could the precmd function determine where the git info ends and the cvs info begins? Perhaps we could have vcs_info return multiple arrays rather than multiple scalars. For example, «typeset -a vcs_info_set_1_» could contain git info and «typeset -a vcs_info_set_2_» could contain cvs info. That would also address the case about git-within-git or hg-within-hg that I mentioned earlier. However, it begs the question, why does vcs_info today use multiple scalars rather than a single array? Cheers, Daniel