Question

因此，我正在做VSTS中的LFS概念验证工作，并且遇到了一个不寻常的问题。我很难证明它应该做的事。基本上，我按照说明添加.gitattributes文件

.gitattributes的内容

*.pdf filter=lfs diff=lfs merge=lfs -text

然后我在根目录下添加了pdf文件并提交

 git add ./3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf    
 git commit -m "some comment"
 output: [Master_Copy_LFSTest 738f4a6] some comment
 1 file changed, 3 insertions(+)
 create mode 100644 3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf

现在，我确实具有本地的.git \ lfs \ objects \ xx \ xx \ bunchoftext，这似乎确实是我的文件，通过移动并重命名为pdf并打开进行了测试。

但是，本地repo根目录中仍然有完整文件，而不是3行指针文件。现在，在这一点上，我推动回购。

  git push origin Master_Copy_LFSTest
  Locking support detected on remote "origin". Consider enabling it with:
  $ git config  

    lfs.https://xxxxxxxx.visualstudio.com/xxxxxx/_git/xxxxx.git/info/lfs.locksverify true
Uploading LFS objects:   0% (0/1), 0 B | 0 B/s                                  
Uploading LFS objects: 100% (1/1), 25 MB | 0 B/s                                
Uploading LFS objects: 100% (1/1), 25 MB | 0 B/s, done
git : To https://xxxxxxx.visualstudio.com/xxxxxxx/_git/xxxxxx
At line:1 char:1
+ git push origin Master_Copy_LFSTest
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (To https://xxxx.../_git/xxxxxx:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

   58a347c..738f4a6  Master_Copy_LFSTest -> Master_Copy_LFSTest

哪种看起来像是可行的，但显然发生了一些未指定错误。

所以它“看起来”像它的工作原理，但我实际上不能说出来。

如果我进入vsts中分支的代码文件查看器，然后单击pdf文件，它将二进制文件加载到我不希望的查看器中，我以为我会看到三行指针文件。这是show的输出

git show 738f4a6
commit 738f4a6bc8a87ce34ab2352bb58a0a44c96be48a
Author: Paul <mememe@mememe.com>
Date:   Thu Jul 19 13:53:37 2018 -0400

    some comment

diff --git a/3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf b/3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf
new file mode 100644
index 0000000..4179d33
--- /dev/null
+++ b/3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:c7aed7138ea8a2f6eda3e22992a52329d2b945c119a517c02056bf8379b92f36
+size 24590383

    git lfs ls-files
c7aed7138e * 3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf

但是真正让我着迷的是，如果我执行VSTS构建并且在获取源代码步骤中不选中LFS中的Checkout文件的框，我仍然会在输出中获取pdf文件（其中一个项目文件引用它总是复制到输出）。如果这确实可行，我将获得指针文件，而不是真正的pdf。

这是第二次尝试中的命令转储

PM> git lfs track "*.pdf"
Tracking "*.pdf"
PM> git lfs ls-files
PM> git lfs ls-files
PM> git add .
PM> git lfs ls-files
e545334f11 * 1.pdf
PM> git commit -m "added file for lfs"
[master_bugs 3840795] added file for lfs
 1 file changed, 3 insertions(+)
 create mode 100644 1.pdf
PM> git push origin master_bugs
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://xxxxxxxxx.visualstudio.com/xxxxxx/_git/xxxxx.git/info/lfs.locksverify true
Uploading LFS objects:   0% (0/1), 0 B | 0 B/s                                  
Uploading LFS objects: 100% (1/1), 2.7 MB | 0 B/s                               
Uploading LFS objects: 100% (1/1), 2.7 MB | 0 B/s, done
git : To https://xxxxxxxx.visualstudio.com/xxxxxxxx/_git/xxxxx
At line:1 char:1
+ git push origin master_bugs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (To https://xxxx.../_git/xxxxx:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

   7c41bfe..3840795  master_bugs -> master_bugs

PM> git config lfs.https://xxxxxxxx.visualstudio.com/xxxxxxxx/_git/xxxxxxx.git/info/lfs.locksverify true
PM> git push origin master_bugs
git : Everything up-to-date
At line:1 char:1
+ git push origin master_bugs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Everything up-to-date:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

PM> git push origin master_bugs
git : Everything up-to-date
At line:1 char:1
+ git push origin master_bugs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Everything up-to-date:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

PM> git show 3840795
commit 3840795646ae042c7d87c34b32ee7235f776f952
Author: Paul <xxxxx@xxxxxxx.com>
Date:   Thu Jul 19 15:58:16 2018 -0400

    added file for lfs

diff --git a/1.pdf b/1.pdf
new file mode 100644
index 0000000..5e46737
--- /dev/null
+++ b/1.pdf
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:e545334f117b7a01e03df7b7d1ba744ff752fdbe28bbfc1178d0a43a95db87cd
+size 2701762
PM> git show 7c41bfe
commit 7c41bfe52faeb8dd4dcb822195c679fc9cb3e4d0
Author: Paul <xxxxx@xxxxxxx.com>
Date:   Thu Jul 19 15:54:11 2018 -0400

    asdsad

diff --git a/.gitattributes b/.gitattributes
index 09d8abc..b634d85 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,3 +1 @@
 *.pdf filter=lfs diff=lfs merge=lfs -text
-"*.pdf" filter=lfs diff=lfs merge=lfs -text
-'*.pdf' filter=lfs diff=lfs merge=lfs -text

我怎么知道这是否正常工作？

Answer 1

您的git repo的pdf文件3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf已经在Git LFS中进行了管理。

通过命令检查时：

git lfs ls-files

提交3FOWW_Rules_of_Play_Digital_Final_v1.3.pdf中738f4a6文件的差异也表明该文件是在git lfs中管理的，如消息所示：

version https://git-lfs.github.com/spec/v1

因此，您的主要困惑似乎是为什么即使在VSTS构建“获取源代码”步骤中从LFS选项中取消选择“签出文件”时，仍可以看到lfs文件的原因。

实际上如果未选择选项“从LFS检出文件”，则不会下载LFS文件的内容。您可以通过 lfs文件的大小仔细检查。

就像我在git lfs中管理11.png文件一样，当我在“获取源代码”步骤中取消选择“从LFS中检出文件”选项时，文件11.png为1KB。而且，如果我在“获取源代码”步骤中选择“从LFS中检出文件”选项并重新构建，则文件11.png为83KB。

带有LFS的VSTS-如何判断其是否真正起作用

1 个答案: