简体   繁体   English

如何将 Git LFS 文件的旧版本打印到标准输出(LFS 的 git show / git cat-file)?

[英]How to print a Git LFS file's old version to stdout (git show / git cat-file for LFS)?

Another title for this question could be 'How to checkout multiple versions of a Git-LFS managed file?'这个问题的另一个标题可能是“如何检出 Git-LFS 托管文件的多个版本?”

I would like to inspect several versions of a file stored in Git-LFS.我想检查存储在 Git-LFS 中的文件的多个版本。 I would therefore like to several versions of this file side-by-side in my working directory.因此,我希望在我的工作目录中并排放置此文件的多个版本。 Something like this is what I have in mind:像这样的事情是我的想法:

git show v1:./myfile.ipynb > myfile-v1.ipynb
git show v2:./myfile.ipynb > myfile-v2.ipynb

This does not work as desired: the file is managed by Git-LFS, so to git show its contents at each version looks like这不能按预期工作:文件由 Git-LFS 管理,因此在每个版本中git show其内容看起来像

version https://git-lfs.github.com/spec/v1
oid sha256:62aafe00ec8b61a37dd729e7d3a723382...
size 20439

I am interested in the file's 'true', Git-LFS-managed contents, rather than the pointer file that LFS stores in Git's own tree.我对文件的“真实”、Git-LFS 管理的内容感兴趣,而不是 LFS 存储在 Git 自己的树中的指针文件。

How can I create untracked, custom-named files that each contain a specific version of a file tracked by Git-LFS?如何创建未跟踪的、自定义命名的文件,每个文件都包含 Git-LFS 跟踪的文件的特定版本? This does not need to be a single command, I am resigned to Git needing multi-step scripts for single-concept actions.这不需要是一个单一的命令,我接受了 Git,需要用于单一概念操作的多步骤脚本。

Piping an lfs pointer into git lfs smudge will yield you what you want.将 lfs 指针放入git lfs smudge会得到你想要的。 For example:例如:

git cat-file blob <blob-sha> | git lfs smudge

Or if you have a commit-ish (a commit hash, branch name, just HEAD , etc.) and a file name:或者,如果您有一个 commit-ish(一个提交哈希、分支名称、只是HEAD等)和一个文件名:

git cat-file blob <commit-ish>:path/to/my-large-file.name | git lfs smudge

You could redirect the output into a file.您可以将输出重定向到文件中。

Update : @Markonius' answer is the proper way to do it.更新@Markonius 的回答是正确的方法。

Here is a script that does this based on experimenting with an LFS repository.这是一个基于对 LFS 存储库进行试验的脚本。 I didn't look at the LFS protocol in details, so there might be quirks unaccounted for, but it worked for my simple case.我没有详细查看 LFS 协议,因此可能存在无法解释的怪癖,但它适用于我的简单案例。

git-lfs-cat-file git-lfs-cat-文件

The relevant details are:相关详情如下:

  • LFS files are stored in the index with the following structure: LFS 文件存储在索引中,结构如下:

     version https://git-lfs.github.com/spec/v1 oid sha256:abcdeffffffffffffff size nnnnnnnn
  • Actual LFS object will then be under .git/lfs/objects/ab/cd/abcdeffffffffffffff .实际的 LFS 对象将在.git/lfs/objects/ab/cd/abcdeffffffffffffff

When last I was working with LFS, there were conversations on the project page about better integration - such as by writing diff and/or merge tools that could be plugged in via .gitattributes .上次我使用 LFS 时,项目页面上有关于更好的集成的对话 - 例如通过编写可以通过.gitattributes插入的差异和/或合并工具。 These didn't seem to be considered high priority, since the main intended use case of LFS is to protect large binary files (but certainly I've come across multiple cases where either I had a large text file, or the only reasonable way to set up LFS tracking rules cast a wide enough net to catch some smaller text files).这些似乎并没有被视为高优先级,因为 LFS 的主要预期用例是保护大型二进制文件(但我当然遇到过多种情况,其中要么我有一个大文本文件,要么是唯一合理的方法设置 LFS 跟踪规则投射足够宽的网络以捕获一些较小的文本文件)。 I'm not sure if there's been any progress on those tools, as I haven't looked at the project page in a while.我不确定这些工具是否有任何进展,因为我有一段时间没有查看项目页面。

Absent those things, there's not a particularly "slick" way to do what you're asking.如果没有这些东西,就没有一种特别“巧妙”的方式来做你所要求的事情。 You can set up two work trees and check out different versions.您可以设置两个工作树并检查不同的版本。 You can check out one version, rename it, and then check out the other.您可以检出一个版本,重命名它,然后检出另一个。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM