如何判断文件是否正确上传到git lfs? [英] How can I tell if a file will be uploaded to git lfs correctly?

问题描述

我正在尝试将MyProject/Frameworks/下的所有内容添加到 git-lfs (大文件存储) .我不确定哪种递归匹配所有文件和文件夹的正确格式在Frameworks文件夹下. 此答案说正确的格式为git lfs track "MyProject/Frameworks/**"，但.我都尝试过，他们没有使用git lfs进行存储.它尝试直接上传文件.

I'm trying to add everything under MyProject/Frameworks/ to git-lfs (large file storage). I'm not sure what the proper format for matching all files and folders recursively under the Frameworks folder is. This answer says the proper format is git lfs track "MyProject/Frameworks/**", but Atlassian's help document says I should use git lfs track "MyProject/Frameworks/". I tried both and they didn't use git lfs for storage. It tried uploading files directly.

当然，我想知道正确的格式，但是更重要的是，在尝试将更改推送到github之前，我想验证匹配项和文件确实可以正常工作.这将允许我迭代并尝试新事物.

Sure, I'd love to know the proper format, but more importantly, before I attempt to push my changes to github, I'd like to verify that the match and files do indeed work correctly. This'll allow me to iterate and try new things.

我看到两个可能有用的相关命令:

I see two related commands that might help: git lfs status and git lfs ls-files. It's not clear which one I should be using and what output I should be looking for. For example, when I ran git lfs status, it showed me a ton of files under Git LFS objects to be committed, making me think they would be added to Git LFS. However, after attempting to push to GitHub.com, I realized that it was clearly not the case. If it helps, the output for these files always had something like (Git: edee1ad) after each file name.

当我尝试使用git lfs ls-files时，我不确定是否需要在git add提交文件之后，提交文件或推送文件之后运行它.在大多数情况下，它只是向我显示空白输出.

When I attempt to use git lfs ls-files I'm not sure if I need to run it after git adding the files, after committing them, or after pushing them. Most of the time it's just showing me blank output.

本质上，问题是:如果我正确配置了git lfs，我应该使用什么工具(例如git lfs status)，以及在 之前应该寻找什么输出? /push?

Essentially the question is: If I configured git lfs correctly, what tool (e.g. git lfs status) should I use, and what output should I look for before I attempt to commit/push?

注意:请不要仅使用 回答问题，该如何匹配所有递归文件，因为这将对我有一次帮助(此特定情况)，而不是允许我迭代并尝试新事物(在任何情况下).

Note: Please don't answer the question with only how to match all recursive files as that will help me once (this specific case), rather than allowing me to iterate and try new things (any case).

推荐答案

TL; DR

如果一切设置正确，则可以通过以下方法验证git LFS是否可以正常工作:

If everything is set up correctly, you can verify that git LFS is going to work properly by:

1. git add有问题的文件.
2. 执行以下操作之一:
   • 运行git lfs status并确保所讨论的文件出现在Git LFS objects to be committed下，并且在括号中具有LFS值；或
   • 运行git lfs ls-files并确保有问题的文件出现在此输出中.

1. git add the file(s) in question.
2. Do one of the following:
   • Run git lfs status and ensure the file(s) in question appear under Git LFS objects to be committed, and that they have the LFS value in parenthesis; or
   • Run git lfs ls-files and ensure the file(s) in question appear in this output.

⚠️重要:运行git lfs track后，必须运行git add刷新文件的状态，然后再调用git lfs status或git lfs ls-files.否则，您将看到这些命令的不相关输出.

⚠️ Important: After running git lfs track, you must run git add to refresh the state of files before calling git lfs status or git lfs ls-files. Otherwise you'll see irrelevant output from those commands.

记录下来，看起来git lfs track "MyProject/Frameworks/**"是递归匹配的正确方法.

Also, for the record, looks like git lfs track "MyProject/Frameworks/**" is the correct one for recursive matching.

设置和测试方法:

1. git lfs track "*.lfs".这将生成.gitattributes.使其保持未登台状态.
2. 在根目录Test.lfs中创建一个文件.使其保持未登台状态.

3. 测试:

1. git lfs track "*.lfs". This generates .gitattributes. Leave it unstaged.
2. Create a file in the root directory, Test.lfs. Leave it unstaged.

3. Test:

• git lfs status:没有文件名输出

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:


Git LFS objects to be committed:


Git LFS objects not staged for commit:


$

git lfs ls-files:无输出

git lfs ls-files: no output

$ git lfs ls-files
$

添加git add Test.lfs.

测试:

• git lfs status:Test.lfs现在将带有LFS后缀列出.

• git lfs status: Test.lfs will now be listed with an LFS suffix.

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:


Git LFS objects to be committed:

        Test.lfs (LFS: 2ab9f1e)

Git LFS objects not staged for commit:


$

git lfs ls-files:Test.lfs现在将列出.

git lfs ls-files: Test.lfs will now be listed.

$ git lfs ls-files
2ab9f1e447 * Test.lfs
$

提交更改.

测试:

• git lfs status:Test.lfs将移至被推动"部分.它的后缀是一堆数字/字母.

• git lfs status: Test.lfs will move to the "to be pushed" section. It will have a suffix such with a bunch of numbers/letters.

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:

        Test.lfs (2ab9f1e44720efb7a26553e06b667a270320efb3e906553b3f9e0702538a2b3f)

Git LFS objects to be committed:


Git LFS objects not staged for commit:


$

git lfs ls-files:Test.lfs将继续列出.

git lfs ls-files: Test.lfs will continue to be listed.

$ git lfs ls-files
2ab9f1e447 * Test.lfs
$

测试:

• git lfs status:不再输出文件名

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:


Git LFS objects to be committed:


Git LFS objects not staged for commit:


$

git lfs ls-files:继续输出跟踪的文件

git lfs ls-files: Continues to output the tracked file

$ git lfs ls-files
2ab9f1e447 * Test.lfs
$

结论:

• Git LFS objects not staged for commit部分似乎具有误导性，因为它从未显示过任何文件，即使是本应由LFS跟踪的文件也是如此.
• 如果您尝试对非git-lfs跟踪的文件进行先前的实验，您还会注意到该文件错误地出现在Git LFS objects to be committed下.它不是Git LFS对象.您可以确定它实际上不是Git LFS对象的方法是查看其结束方式.如果它以(Git: 111111111)结尾，则不会提交给LFS.
• 为避免上述混乱，您可能希望使用git lfs ls-files而不是git lfs status来确定某些内容是否将成为git-lfs的一部分.
• 另一个陷阱:诸如Xcode之类的某些应用程序将以一种奇怪的方式git add文件，导致对于Git LFS不应该考虑的明显匹配项.解决方案是先取消暂存文件，然后重新暂存它们.

• The Git LFS objects not staged for commit section seems misleading as it never displayed any files, even those that should have been tracked by LFS.
• If you attempt to do the previous experiment with a non git-lfs tracked file, you'll also notice that it appears under the Git LFS objects to be committed incorrectly. It is not a Git LFS object. The way you can tell that it's not actually a Git LFS object though is to look at how it ends. If it ends with (Git: 111111111) it won't be committed to LFS.
• To avoid the above confusions, you may want to favor git lfs ls-files over git lfs status to determine if something is going to be part of git-lfs or not.
• Another gotcha: Some applications such as Xcode will git add files in a weird way causing what should have been clear matches to not be considered for Git LFS. The solution is to unstage the files and then re-stage them.

这篇关于如何判断文件是否正确上传到git lfs?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！