Subject: Re: [PATCH] dir: use per-worktree repository ignore patterns upon request

From: Junio C Hamano <[email-masked]>
Date: Sat, 25 Apr 2026 12:06:34 +0900

Phillip Wood <[email-masked]> writes:

> Sharing the same set of exclude patterns between all worktrees seems 
> like a reasonable thing to do - it would be a pain to have to populate 
> them every time a new worktree was created.
>
> 	git rev-parse --git-path info/exclude
>
> always returns the correct path because it uses repo_git_path() which 
> knows whether a particular path is per-worktree or resides under 
> $GIT_COMMON_DIR. It is best to avoid constructing paths manually using 
> "git rev-parse --git-dir"

Great to see the best practice raised, like this.

>> Some users may prefer each worktree use its own ignore file; some may
>> prefer both; some may prefer the current behavior.
>
> This sounds quite hypothetical - do we have a concrete use case for 
> per-worktree exclude files?

I can see if somebody wants to have different subset of paths
checked out by setting up separate sparse settings.  But marking
what paths are never be part of the project (which is what exclude
is about)?  I do not think it is useful in general.

The only case I can think of is a repository that houses more than
one completely unrelated histories, perhaps being cheapster on a
hosting site that charges per number of repositories or something
silly like that.

My https://git.kernel.org/pub/scm/git/git.git/ repository houses two
completely unrelated histories, one the project data, and 'todo'
that are mostly about tools I personally use to maintain the
project.  Ideally, the latter branch should have been created and
maintained as a separate repository, but back them I didn't have
write access outside pub/scm/git/git.git/ (notably pub/scm/git/
itself was not writable to me) and that was the only reason why that
unrelated history is pushed into the same repository as a separate
and unrelated 'todo' branch.  It is not a recommended practice, and
if this configuration is primarily to cater to such layout, I do not
think we want to add it.