我使用git fetch <remote> --depth=<N>
解决了向我的本地存储库添加远程的超时问题。尝试git fetch <remote>
而不指定深度会超时。所以我尝试git fetch <remote> --depth=10
然后反复fetch
越来越多,每次都稳定地增加深度,直到我终于能够得到整个事物(即增加深度检索零对象)。之后我运行git fetch <remote> --unshallow
is supposed to convert the remote back to a non-shallow remote copy。
这是我的问题。完成所有这些之后,我不确定我的本地存储库是否处于与开始时刚刚完成git fetch <remote>
时相同/等效的状态,并且它没有超时。每次我git fetch <remote>
时,它都会报告相同的“新”和“更新”分支。
发生了什么,我该如何纠正?
我唯一可以想到的尝试,我还没有尝试过,就是删除遥控器并再次添加它。我害怕不得不重新开始。这是一个非常大的存储库,需要很长时间才能达到这一点。如果我在此期间避免使用git gc
,那么删除并重新添加遥控器是否允许分支重置而无需再次下载所有提交?
这是我所做的和结果。
每当我git fetch <remote>
现在,无论我尝试什么,我都会得到这个输出:
Fetching <remote>
From ssh://<url>
+ 3603285...775e0fe Feature/A -> <remote>/Feature/A (forced update)
+ 6303337...de89a23 Feature/B -> <remote>/Feature/B (forced update)
* [new branch] feature/C -> <remote>/feature/C
* [new branch] feature/D -> <remote>/feature/D
* [new branch] feature/E -> <remote>/feature/E
* [new branch] feature/F -> <remote>/feature/F
* [new branch] feature/G -> <remote>/feature/G
* [new branch] feature/H -> <remote>/feature/H
每次都输出相同的输出。其他遥控器不是这样的。它只出现在这个遥控器上,分支指针实际上永远不会先进,每个fetch
都会尝试再次推进它们。输出中从不存在任何实际错误。
我已经确认这些分支都存在于远程服务器中,并且不会在那里删除。但是,检查远程仓库上的分支Feature/A
的整个提交历史记录,它根本不包含提交3603285
。
git config --get remote.<remote>.fetch
的输出:
+refs/heads/*:refs/remotes/<remote>/*
git remote show <remote>
的部分输出:
Remote branches:
feature/X tracked
feature/Y tracked
feature/A tracked
feature/B tracked
refs/remotes/<remote>feature/C stale (use 'git remote prune' to remove)
refs/remotes/<remote>feature/D stale (use 'git remote prune' to remove)
refs/remotes/<remote>feature/E stale (use 'git remote prune' to remove)
refs/remotes/<remote>feature/F stale (use 'git remote prune' to remove)
refs/remotes/<remote>feature/G stale (use 'git remote prune' to remove)
refs/remotes/<remote>feature/H stale (use 'git remote prune' to remove)
我尝试的事情没有纠正这个:
git fsck
(不报告任何问题)git fetch <remote> --unshallow
(报告存储库已经完成)git gc
(未报告任何错误,运行两次会产生相同的输出)git remote prune <remote>
(将分支C
删除为H
,但会在下一个fetch
上重新添加git fetch --all --prune
git fetch --all --prune
的输出略有不同(无论我尝试什么,每次都是这样):
Fetching <remote>
From ssh://<url>
x [deleted] (none) -> <remote>/Feature/C
x [deleted] (none) -> <remote>/Feature/D
x [deleted] (none) -> <remote>/Feature/E
x [deleted] (none) -> <remote>/Feature/F
x [deleted] (none) -> <remote>/Feature/G
x [deleted] (none) -> <remote>/Feature/H
+ 3603285...775e0fe Feature/A -> <remote>/Feature/A (forced update)
+ 6303337...de89a23 Feature/B -> <remote>/Feature/B (forced update)
* [new branch] feature/C -> <remote>/feature/C
* [new branch] feature/D -> <remote>/feature/D
* [new branch] feature/E -> <remote>/feature/E
* [new branch] feature/F -> <remote>/feature/F
* [new branch] feature/G -> <remote>/feature/G
* [new branch] feature/H -> <remote>/feature/H
如果我签出分支<remote>/Feature/A
,我会提交3603285
而不是775e0fe
,即使在远程服务器上,Feature/A
指向775e0fe
和{{ 1}}在历史上无处可去。我也可以直接通过提交字符串检查3603285
而不会出现问题。这一系列命令产生的输出令我感到惊讶(无论我怎么做,每次都是这样):
775e0fe
答案 0 :(得分:0)
这是一个文件系统案例折叠问题,因此它与浅部分无关(这是一种好消息/坏消息)。
我看到你这里有feature/<name>
和Feature/<name>
,小写和大写F.你的Git在你的存储库中设置它们,但是一旦它用一个case创建一个目录,分支名称就是另一种情况进入同一目录。你的Git然后认为那些是错的:它必须销毁错误的案例分支并创建它所做的右案例分支,但是你仍然有错误的案例名称,因为你的操作系统再次折叠案例并将所有内容写入现有的其他案例目录。
通常的解决方案是使用不折叠案例的操作系统(或文件系统),或修复上游使用单个案例。
如果那是不可能的,我有一个想法,我从未测试过,但应该工作:你可以拆分你的fetch
网址。这有各种缺点,主要原因是您必须偶尔手动运行git ls-remote
并检查是否需要更新URL映射。 (使用一种比较常见的解决方案要好得多。)