Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] vcs_info: add 'find-deepest' zstyle
- X-seq: zsh-workers 47497
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: Oliver Kiddle <opk@xxxxxxx>
- Subject: Re: [PATCH] vcs_info: add 'find-deepest' zstyle
- Date: Sun, 25 Oct 2020 19:54:01 +0000
- Archived-at: <https://zsh.org/workers/47497>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-10/20201025195401.3c54c6a2%40tarpaulin.shahaf.local2>
- Authentication-results: zsh.org; iprev=pass (out4-smtp.messagingengine.com) smtp.remote-ip=66.111.4.28; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none
- Cc: Frank Terbeck <ft@xxxxxxx>, zsh-workers@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=fm1; bh=NBjQNuvyic/KJHss+H98UWgywj XCdOGG2rvXfKfuwWs=; b=UOtemN8jd96MRmb2IfCX1Nybw9+3Dt4/vgyvSEcX3f 3yyMjoBA4MEat6cvNJ0TZfSHrbBP1ZUqDv+kpqDPSksKmLRpShiJ/BZDGgAEneNP ekDY9nkXXFcCeeWC0xIotYoenhbT51Mjgkv35ROsV5J4X4iNjFq4HKhrl3otjRpD +LvHjrSrOr2C7WM+RnQ+z/55CmLMPt6EWOf0I88/zoicYAwTePXSMW3KZ2BI/LoN fJQjsibEgSmEyJUxh8vTMVr0fB4y7YnjOZaTfdVoJzxuciTkH3mTOT32t+wo7N+8 YEiMKWLyoq9mSAn1wkD5UxdpwEGORGLE64gS2TY41hgw==
- 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=NBjQNuvyic/KJHss+H98UWgywjXCdOGG2rvXfKfuw Ws=; b=TjyqlBpG881AxXYUIWDGX9eoUscRxGwKx8iNnxNbXQ0t7jroGOUMXX1j8 GnCMgB4bahN5kJtgxNSlTRZqt9mWhzSgy7utiGHgcGSZKvLR1ZhQXmnVj0ll4wTx 4cL36XpcAcogKcmhToeu65pCC9KnjisT0FtIx9cdIl3E2fQF0CNfL6pAJzTwfnVe ot5RWokdv7A9PxNHx2rp8PA09H+gAuR9ANX0j4QoaEz2aizOvAZMMJJJHFyzsf6z QhHa5ULpgUsFxwXFv7FAXqSfaeh/HUjXyi0XRt4j1/q5aTR7x2Nj6w5bg5QOcQcz 0pRwcoyFPspnc2Z/wk49yQKLnQJtw==
- In-reply-to: <37168-1603506679.130606@RR8o.26Eg.GGvC>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:sympa@zsh.org?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:zsh-workers-request@zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-subscribe: <mailto:sympa@zsh.org?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:sympa@zsh.org?subject=unsubscribe%20zsh-workers>
- References: <20201023083444.1565608-1-mezin.alexander@gmail.com> <20201023234855.5a0c6290@tarpaulin.shahaf.local2> <87mu0clbw2.fsf@ft.bewatermyfriend.org> <37168-1603506679.130606@RR8o.26Eg.GGvC>
- Sender: zsh-workers-request@xxxxxxx
Oliver Kiddle wrote on Sat, 24 Oct 2020 04:31 +0200:
> Long detection times can still very much be a problem. At both home
> and work, I use automount and NFS home directories so the NFS server
> regularly gets queried for non-existent homes named .git etc. [...]
>
> I suspect some of this could be avoided by doing something similar to
> the find -xdev option to stop searching when a different filesystem is
> reached.
So you'd like to assume that a single worktree will not cross into
nested mount points.
I'm not actually sure this is true every time. For instance, if
a project's tree is huge and someone works only on part of it but has
multiple worktrees for that project, they might use bind mounts for the
parts of the tree they never touch; and conversely, people doing in-tree
builds might mount ramdisks inside their worktrees to generate the
object files and executables in, and then cd into those and expect to
still see the info for the enclosing worktree.
Whether any of these use-cases is a deal breaker is another question.
How about, if cwd is writable (in the access(W_OK) sense), stopping the
upwards crawl when reaching a directory that isn't writable? This would
typically stop on «~/../».
> I don't have much use for nested repositories but vcs_info tends to be
> more use with git than subversion.
+1, primarily because git is much more stateful (e.g., interrupted
rebases).
Cheers,
Daniel
Messages sorted by:
Reverse Date,
Date,
Thread,
Author