.gitignore包含所有内容的SQLServerTypes文件夹
我正在使用官方的 Visual Studio .gitignore。
https://github.com/github/gitignore/blob/main/VisualStudio。 gitignore
我在嵌套文件夹中有项目，例如：
/MySolution/src/MyProject1/SqlServerTypes/...
/MySolution/src/MyProject2/SqlServerTypes/...
/MySolution/src/MyProject3/SqlServerTypes/...
/MySolution/src/MyProject4/SqlServerTypes/...
...
/MySolution/src/MyProjectN/SqlServerTypes/...
可以有多个项目，但我需要将 SqlServerTypes 文件夹及其所有路径上的所有内容列入白名单。这怎么可能？
!SqlServerTypes/*
!SqlServerTypes/**
!SqlServerTypes/**/*.dll
!SqlServerTypes/x64/*.dll
!SqlServerTypes/x86/*.dll
这对我不起作用。它位于 .gitignore 文件的底部。 在根文件夹中写入 git rm -r --cached . 和 git add . 时，不包括我的 SqlServerTypes 文件夹中的 .dll 。
gitlab.com 上显示的存储库内容：
- 如您所见，dll 以及 x64 和 x86 文件夹不存在。
使用 SqlServerTypes NuGet 包进行项目需要此行为，因为安装该包时，该文件夹会自动添加到项目中，但删除后不会刷新。因此，当忽略这些文件时，尽管“已安装”，但 NuGet 包无法正常工作。
谢谢，非常感谢任何帮助
I am using the official Visual Studio .gitignore.
https://github.com/github/gitignore/blob/main/VisualStudio.gitignore
I have projects in a nested folder, say:
/MySolution/src/MyProject1/SqlServerTypes/...
/MySolution/src/MyProject2/SqlServerTypes/...
/MySolution/src/MyProject3/SqlServerTypes/...
/MySolution/src/MyProject4/SqlServerTypes/...
...
/MySolution/src/MyProjectN/SqlServerTypes/...
There can be multiple projects but I need to whitelist SqlServerTypes folder and all its contents on any path. How is this possible?
!SqlServerTypes/*
!SqlServerTypes/**
!SqlServerTypes/**/*.dll
!SqlServerTypes/x64/*.dll
!SqlServerTypes/x86/*.dll
This did not work for me. It is placed at the bottom of the .gitignore file.
When writing git rm -r --cached . and git add . in the root folder, the .dlls from my SqlServerTypes folders are not included.
The contents of the repository as seen on gitlab.com:
- as you can see, the dlls and the x64 and x86 folders are not present.
This behavior is required for using SqlServerTypes NuGet package for projects because installing the package, the folder is automatically added to the project, but it is not refreshed after deleted. Because of this, when the files are ignored, the NuGet package does not work correctly, although "installed".
Thank you, any help is very appreciated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的问题中没有足够的信息来绝对确定这一点（例如，您可能有子模块），但最有可能的问题是这句话所涵盖的
.gitignore指令的常见问题（其中，显然，许多人感到困惑）来自文档：理解这句话的方法是认识到 Git 在扫描工作树的文件和目录（文件夹）时遵循一个简单的算法：
README.txt、.git、file.ext、main.py< /code>、main.pyc、subdir等，执行“检查忽略”算法。对于文件：
如果文件未被忽略，并且当前不在 Git 索引中，请抱怨该文件未跟踪（
git status）或继续添加它（git add与任何集体样式添加，添加所有内容并查看此文件）。如果文件被忽略并且现在不在 Git 的索引中，请保持安静（
git status：对未跟踪的情况闭嘴）或不执行任何操作（< code>git add：忽略它）。如果文件被忽略，但现在在 Git 索引中，则它并未真正被忽略：检查其状态 (
git status) 或添加它（git add）。对于目录（文件夹）：
如果它被忽略，甚至不要阅读它。如果没有被忽略，请阅读它并对其内容执行三个规则。
（任何包含存储库的
.git目录总是被完全忽略或根据需要转换为子模块 gitlink。您不能强制将.git包含在存储库中：Git绝对拒绝嵌套存储库。1）由于规则 3b 通过不查看内部来处理被忽略的目录，如果 Git 到达：
并且，例如
SqlServerTypes本身被忽略，Git 不会费心去读取/MySolution/src/MyProject1/SqlServerTypes/目录。现在，看看 https://github.com/github/gitignore/blob/ main/VisualStudio.gitignore （你不应该仅仅引用它，你应该在你的问题中包含任何重要的行）我发现第 24 和 25 行如下：
这里的尾部斜杠告诉 Git，当
x64和x86是目录时，应该忽略它们，因此 Git 不会费心查看内部 <代码>/MySolution/src/MyProject1/SqlServerTypes/x64。您试图用以下方法覆盖它：对你来说不幸的是，这一行意味着：2
而不是：
你可能想要的是：
例如，这样Git就会在
/MySolution/src/中查找MyProject1/SqlServerTypes/x64/。或者，如果它不包含太多内容，您可以简单地列出
!x64/和/或!x86/来覆盖第 24 行和第 25 行中的规则。1拒绝嵌套存储库的重点是安全性。早期，Git 无意中允许人们存储
.GIT/或.Git/，这对于区分大小写的典型 Linux 设置来说并不是一个安全漏洞，但是 是典型 Windows 和 macOS 设置上的安全漏洞，但事实并非如此。此后，Git 已变得更加智能，可以拒绝.git、.gIT等，无论大小写混合如何。2原因有点复杂。一些
.gitignore行应用于每个名称组件，有些则应用于迄今为止在上述扫描过程中实现的完整路径名称。完整路径名称限制适用于以下情况：.gitignore中的名称以斜杠开头，或者.gitignore中的名称删除单个尾随斜杠（如果存在）后包含斜杠。。第二条规则是最让你痛苦的规则。 “删除单个尾随斜杠（如果存在）后”只是因为
.gitignore条目可以通过附加斜杠来标记为“仅适用于目录名称”：意味着忽略最后一个的任何内容name 组件是
foo并且是一个目录，而：表示忽略姓氏组件是
foo的任何内容，无论是否是目录 。所以最后一个斜杠被删除了。但是：或：
在删除任何尾部斜杠后，仍然包含至少一个斜杠，因此它的处理方式与：
或：
由于
.gitignore文件可以出现在在工作树中，这些“锚定”规则（我称之为“锚定”规则）不一定仅适用于顶层。相反，它们适用于找到.gitignore的级别。例如，一个工作树在其顶层包含subdir和subdir/.gitignore，其中subdir/.gitignore列出了foo/ bar，忽略/subdir/foo/bar/baz（如果存在），但不忽略/foo/bar或/foo/bar/baz< /code> 如果存在的话。请注意，这里的扫描过程很大程度上涉及操作系统强制 Git 进行的整个目录/文件区分。然而，在一次集体
git add .之后——或者事实上，任何git add——只有文件，不是任何目录，出现在 Git 的索引中。无论您在此处执行什么操作，都无法将目录放入 Git 的索引中。3 而且，由于 Git 从其索引下一个提交em>，Git 索引中缺少目录意味着 Git 提交不会包含除文件之外的任何内容。3有一个技巧可以发挥作用，只不过空目录最终会变成 gitlink，充当半途而废的子模块。4 同时，子模块 - < em>使用 gitlinks，或者使用
mode 160000的索引条目 - 还允许您在存储库中存储空目录，有点：空目录可能会以.git子目录。请参阅如何将空白目录添加到 Git 存储库？4gitlink 提供路径; .gitmodules 文件完成了子模块，如果没有 .gitmodules 文件，您最终会得到一个损坏的子模块，或者我有时称之为半途而废的子模块。通过完全升级
There's not enough information in your question to be absolutely sure of this (e.g., you might have submodules), but most likely the problem is the usual one with
.gitignoredirectives that is covered by this sentence (which, apparently, many people find confusing) from the documentation:The way to understand this sentence is to realize that Git follows a simple algorithm when scanning a working tree's files and directories (folders):
README.txt,.git,file.ext,main.py,main.pyc,subdir, and so on, execute the "check ignore" algorithm.For files:
If the file isn't ignored, and isn't in Git's index right now, gripe that the file is untracked (
git status) or go ahead and add it (git addwith any en-masse style add that adds everything and sees this file).If the file is ignored and isn't in Git's index right now, be quiet (
git status: shut up about untracked-ness) or do nothing (git add: ignore it).If the file is ignored but is in Git's index right now, it's not really ignored: check its status (
git status) or add it (git add).For directories (folders):
If it's ignored, don't even read it. If it's not ignored, read it and execute the three rules on its contents.
(Any
.gitdirectory containing a repository is always either ignored entirely or converted to a submodule gitlink as appropriate. You cannot force a.gitto be included in a repository: Git absolutely refuses to nest repositories.1)Since rule 3b handles ignored directories by not looking inside them, if Git ever reaches:
and, say,
SqlServerTypesitself is ignored, Git won't bother to read the/MySolution/src/MyProject1/SqlServerTypes/directory.Now, looking at https://github.com/github/gitignore/blob/main/VisualStudio.gitignore (which you should not just refer to—you should include any important lines from this in your question) I find that lines 24 and 25 read:
The trailing slash here tells Git that
x64andx86should be ignored when they're directories, so Git won't bother to look inside/MySolution/src/MyProject1/SqlServerTypes/x64. You attempted to override this with:Unfortunately for you, this line means:2
and not:
What you might want here is:
for instance, so that Git will look inside
/MySolution/src/MyProject1/SqlServerTypes/x64/.Alternatively, if it doesn't include too much, you can simply list
!x64/and/or!x86/to override the rules from lines 24 and 25.1The point of refusing nested repositories is security. Early on, Git accidentally allowed people to store a
.GIT/or.Git/, which was not a security hole on typical Linux setups which are case sensitive, but was a security hole on typical Windows and macOS setups which are not. Git has since been smartened-up to reject.git,.gIT, and so on, regardless of upper/lower-case mix.2The reason for this is a bit complicated. Some
.gitignorelines are applied to every name component and some are applied to the full path name achieved so far in the scanning process outlined above. The full-path-name restriction applies if:.gitignorestarts with a slash, or.gitignorecontains a slash after removing a single trailing slash if present.That second rule is the one biting you here. The "after removing a single trailing slash if present" is simply because
.gitignoreentries can be marked as "applies only to a directory name" by appending a slash:means do ignore anything whose last name component is
fooand is a directory, while:means do ignore anything whose last name component is
foo, directory or not. So that last slash gets stripped. But:or:
still contains at least one slash after stripping any trailing slash, so it's treated the same as:
or:
Since
.gitignorefiles can appear at any level within the working tree, these "anchored" rules, as I call them, don't necessarily apply only at the top level. Instead, they apply at the level at which the.gitignorewas found. For instance, a working tree containingsubdirandsubdir/.gitignoreat its top level, wheresubdir/.gitignorelistsfoo/bar, ignores/subdir/foo/bar/bazif that exists, but not/foo/baror/foo/bar/bazif those exist.Note that the scanning process here is heavily involved in this whole directory / file distinction that OSes force upon Git. However, after an en-masse
git add .—or in fact, anygit add—only files, not any directories, appear in Git's index. You cannot get a directory into Git's index, no matter what you do here.3 And, since Git makes the next commit from whatever is in its index, the absence of directories in Git's index means that no Git commit ever contains anything except files.3There's one trick that sort-of-works, except that the empty directories eventually turn into gitlinks, which act as half-assed submodules.4 Meanwhile, submodules—which use gitlinks, or index entries with
mode 160000—also allow you to store an empty directory in a repository, sort of: the empty directory may wind up with a.gitsubdirectory. See How can I add a blank directory to a Git repository?4The gitlink provides the path; a
.gitmodulesfile completes the submodule, and without a.gitmodulesfile, you end up with a broken submodule, or as I sometimes call it, a half-assed submodule. By fully-assing-up ???? the submodule, we fix that problem, only to find a.gitpresent after runninggit submodule update --initor using recursive clone. So you might as well just create an empty.gitignoreor other dot-file.