【问题标题】:Git ls-files behaviourGit ls 文件行为
【发布时间】:2016-03-27 20:36:57
【问题描述】:

尚不清楚git ls-files 使用通配符 的实际作用。

我从git ls-files *.* 命令开始,它工作正常。它显示了所有底层子目录中版本控制下的所有文件 但现在我想选择一组文件。示例:"Device_*.xml"

所以我执行git ls-files Device_*.xml 但这没有结果?!

我知道该命令区分大小写。怎么了?下面是我使用输出执行的命令列表。使用的 Git 版本:2.6.1.windows.1

D:\GIT\repo>git clean -xdf
D:\GIT\repo>git reset --hard

HEAD 现在位于7de8f5b [IP-826-generic-configuration-management-ticket] 将远程跟踪分支“来源”合并到 IP-826-generic-configuration-management-ticket 中

D:\GIT\repo>git status

在分支 IP-826-generic-configuration-management-ticket

您的分支是最新的'origin/IP-826-generic-configuration-management-ticket'。

Untracked files:
  (use "git add <file>..." to include in what will be committed)

没有添加到提交但存在未跟踪的文件(使用“git add”进行跟踪)

 D:\GIT\repo\Imagepipe\SettingsDB\GeneratedDevicesAllPlatforms>dir Device_*.xml /s

<LOT OF DEVICE_*.xml FILES HERE> 

12/10/2015  10:46               681 Device_GeneratedDevices_0-0-0_0.xml
1 File(s)            681 bytes

 Directory of            D:\GIT\repo\Tools\DevTools\SettingsGenerator\SLIB2_GenerateSettings\Test\DB7\GeneratedDevices\D1
12/10/2015  10:46             1,997 Device_D1_0-0-0_0.xml
1 File(s)          1,997 bytes

 Directory of     D:\GIT\repo\Tools\DevTools\SettingsGenerator\SLIB2_GenerateSettings\Test\DB7\S_NOCHECK

12/10/2015  10:46             1,558 Device_S_NOCHECK_0-0-0_0.xml
1 File(s)          1,558 bytes

 Directory of     D:\GIT\repo\Tools\DevTools\SettingsGenerator\SLIB2_GenerateSettings\Test\DB7\S_TEST

12/10/2015  10:46             1,536 Device_S_TEST_0-0-0_0.xml
1 File(s)          1,536 bytes

Total Files Listed:
         968 File(s)     14,032,982 bytes
           0 Dir(s)  18,400,256,000 bytes free

D:\GIT\repo>git ls-files Device_*.xml
D:\GIT\repo>

**No result!** 

【问题讨论】:

标签: git wildcard git-ls-files


【解决方案1】:

问题在于,如果您在 非字符串 环境中使用星号 (*),命令行解释器将自己执行 扩展:它看起来目录中的文件,在版本控制下不需要并将它们添加为参数。例如,假设目录包含一个文件:

foo-a.txt
foo-b.txt

你调用git ls-files foo-*.txt,实际上你调用命令git ls-files foo-a.txt foo-b.txt。现在有可能foo-c.txt 在版本控制之下,但曾经被删除,而foo-a.txtfoo-b.txt 不在,导致没有列出任何文件。

如果您在字符串环境中使用星号,例如git ls-files "foo-*.txt"星号将由git解释。所以如果仓库中存在与通配符匹配的文件,就会被返回。

示例

> git init 
Initialized empty Git repository in /foo/bar/.git/
> ls
> touch foo-c.txt 
> git add .; git commit -am 'foo-c'
[master (root-commit) 3523fc3] foo-c
 1 file changed, 1 insertion(+)
 create mode 100644 foo-c.txt
> rm foo-c.txt 
> git ls-files
foo-c.txt
> git ls-files foo-*.txt
fish: No matches for wildcard 'foo-*.txt'.
git ls-files foo-*.txt
             ^
> git ls-files 'foo-*.txt'
foo-c.txt
> touch foo-a.txt
> touch foo-b.txt
> git ls-files 'foo-*.txt'
foo-c.txt
> git ls-files foo-*.txt

在示例中,我们首先设置了一个 git 存储库,然后我们创建了一个文件 foo-c.txt。现在我们添加该文件并进行提交。接下来我们删除文件。如果我们现在调用git ls-files foo-*.txt,它是fish(shell)抱怨找不到这样的文件。但是,如果我们在字符串中传递foo-*.txt,则git 匹配foo-c.txt 没有问题。

如果我们稍后将foo-a.txtfoo-b.txt添加到目录中,通过在字符串环境之外执行通配符,git得到git ls-files foo-a.txt foo-b.txt,但是由于没有这样的文件被颠覆,它什么也不返回(它不能找到这些文件)。但是,如果您使用带有字符串的通配符,它​​将再次出现foo-c.txt

【讨论】:

  • 我试图在 windows 下重现这个,但第一个“git ls-files foo-*.txt”命令仍然返回 foo-c.txt
  • @MarkdeBont:它应该返回foo-c.txt,因为它是唯一受版本控制的文件。请参阅示例。
猜你喜欢
  • 2021-06-19
  • 1970-01-01
  • 2020-01-03
  • 1970-01-01
  • 2020-08-06
  • 2016-08-13
  • 1970-01-01
  • 2022-07-04
  • 1970-01-01
相关资源
最近更新 更多