【问题标题】:How to shallow clone a local git repository with a relative path?如何浅克隆具有相对路径的本地 git 存储库?
【发布时间】:2018-04-28 16:30:56
【问题描述】:

本地目录的浅层克隆需要file://,解释如下:git clone: warning: --depth is ignored in local clones; use file:// instead

但是如何使用相对路径呢?

例如:如果我在当前目录中有一个 repo myrepo,然后我这样做:

git clone --depth 1 file://mymodule mymodule2

然后它失败了:

Cloning into 'mymodule2'...
fatal: No path specified. See 'man git-pull' for valid url syntax

如果我尝试:

git clone --depth 1 file://./mymodule mymodule2

它失败了:

Cloning into 'mymodule2'...
fatal: '/./mymodule' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

我能找到的唯一解决方法是将其转换为以/ 开头的绝对路径:

git clone --depth 1 "file://$(pwd)/mymodule" mymodule2

这种行为有什么深刻的原因,还是只是有问题?

也许文件 URI 根本不支持相对路径:

git 2.14.1.

【问题讨论】:

  • 来自 git clone 的文档:git clone C:\folder1 folder2kernel.org/pub/software/scm/git/docs/git-clone.html#URLS
  • @IvanSheigets 但C:\ 不是绝对路径吗?它是否适用于 --depth 而没有 file://?在 Linux 中 --depth 需要 file://
  • 你是对的:URL/URI 根本不允许相对路径。 Git 可能应该在这里拥抱并扩展,以便无论如何都允许它。
  • 这是杀手锏。非常感谢。太多人说这是不可能的。

标签: git


【解决方案1】:

但是如何使用相对路径呢?

不支持; file:// 只需要绝对路径。有例如RFC1738RFC8089 描述了这种 URI。

文件 URL 采用以下形式:

   file://<host>/<path>

系统的完全限定域名在哪里
哪个是可访问的,并且是分层的
形式的目录路径 //.../.

当您编写file://mymodule 时,mymodule 可以解释为主机名。

【讨论】:

    【解决方案2】:

    浅层克隆本地仓库既没有必要也没有好处。只需git clone ./relative/path,您就可以开始了。

    我假设你想要浅拷贝,因为你想节省磁盘空间和时间,但是

    1.它不会在本地克隆中节省磁盘空间。

    来自 Git 2.24.1 手册:

    对于本地存储库,Git 本身也支持,以下语法可能是 使用:

    • /path/to/repo.git/

    • file:///path/to/repo.git/

    这两种语法大部分是等价的,除了前者暗示了--local选项。

    -l, --local

    当要克隆的存储库位于本地计算机上时,此标志绕过正常的“Git 感知”传输机制,并通过复制 HEAD 以及 objects 和 refs 目录下的所有内容来克隆存储库。 .git/objects/ 目录下的文件硬链接以尽可能节省空间

    因此使用file:///path/to/repo.git/ 语法的浅拷贝应该比使用/path/to/repo.git/ 语法的完整拷贝消耗更多的磁盘空间,因为前者具有对象的真实副本而不是硬链接。

    (而且我相信硬链接是设置--local--depth 被忽略的原因。)

    2。它也不节省时间。

    不过,Git 2.24.1 手册:

    -l, --local

    当要克隆的存储库位于本地计算机上时,此标志绕过正常的“Git 感知”传输机制并通过复制 HEAD 以及 objects 和 refs 目录下的所有内容来克隆存储库. .git/objects/ 目录下的文件被硬链接以尽可能节省空间。

    即使 URI 是 file://...,“Git 感知”传输机制也很耗时,因为它包含对象压缩:

    $ time git clone --depth 1 --local --shallow-submodules file://$(pwd)/../linux
    Cloning into 'linux'...
    warning: --local is ignored
    remote: Enumerating objects: 65607, done.
    remote: Counting objects: 100% (65607/65607), done.
    remote: Compressing objects: 100% (61137/61137), done.
    remote: Total 65607 (delta 4886), reused 39965 (delta 3556)
    Receiving objects: 100% (65607/65607), 176.65 MiB | 10.81 MiB/s, done.
    Resolving deltas: 100% (4886/4886), done.
    Updating files: 100% (61793/61793), done.
    git clone --depth 1 --local --shallow-submodules  73.55s user 4.97s system 245% cpu 31.976 total
    

    (不知道为什么我的 NVMe SSD 接收速度是 10.81 MiB/s)

    使用--local 标志进行克隆要快得多:

    $ time git clone ../linux
    Cloning into 'linux'...
    done.
    Updating files: 100% (61793/61793), done.
    git clone ../linux  4.16s user 1.71s system 100% cpu 5.857 total
    

    【讨论】:

    • 感谢您的清晰解释。但是,我不同意您的观点,即它不节省空间并且速度不快。它确实节省了空间,最重要的是,在某些情况下,它确实使事情变得更快(嗯,只是正常的)。在我的情况下,它正在安装的 NFS 共享上工作,并且由于它没有硬链接(可能认为不同的机器),并且在处理许多小文件时运行速度很慢,这是一个真正的问题。所以,在判断“你都错了”之前,想想你不知道的用例。不过谢谢。
    【解决方案3】:

    您应该尝试不使用file:// 前缀:

    git clone --depth 1 ./mymodule mymodule2
    

    【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-02-28
    • 1970-01-01
    • 2019-03-02
    • 2022-12-03
    • 2013-10-21
    • 1970-01-01
    • 2018-06-19
    • 2021-09-18
    相关资源
    最近更新 更多