Jeff King wrote:
> That is not actually a submodule, but rather just a repo that happens to
> be inside our working tree. I know the distinction is subtle, but
> according to the thread I linked to above, we may actually treat paths
> with gitlinked index entries separately already (I did not try it,
Agreed. treat_gitlink() dies if there is a gitlink cache_entry
matching any of the pathspecs; it does one thing well, and promises
what it does: however, its core logic in check_path_for_gitlink() can
easily be moved into lstat_cache_matchlen() as that is more generic
(checks index and worktree). die_if_path_beyond_symlink() is the
perfect example to replicate. Today, there is one more caller of
die_if_path_beyond_symlink(): check-ignore, so we must patch that too.
On a slightly related note treat_path() also contains the logic for
checking for a git repository in the worktree. Unfortunately, the
code cannot be reused because it checks for a '.git' in a dirent.
On the wording issue, a submodule is a submodule whether in-index or
otherwise. I would write two different tests: one for in-worktree
submodule and another for in-index submodule, and name them
appropriately. Does that make sense?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html