标签: git-fetch

当我将远程存储库添加为上游并尝试获取它时,它会失败,如下所示:

    $ git fetch upstream
    remote: Counting objects: 11901, done.
    remote: aborting due to possible repository corruption on the remote side.
    error: pack-objects died of signal 9
    error: git upload-pack: git-pack-objects died with error.
    fatal: git upload-pack: aborting due to possible repository corruption on the re
    mote side.
    fatal: protocol error: bad pack header

我知道它由于存储库中存在大量文件而失败(我们确实有),但为什么克隆相同的存储库时它不会失败？因为我能够成功克隆存储库.不应该在克隆请求时打包相同的对象吗？

我有很多遥控器添加到我的git.每个远程程序都是一个开发人员的存储库 每天我都会fetch --all看到他们创建的任何新分支都可以查看.

但是,开发人员可以将"私有"分支推送到远程.比如,所有以下划线前缀命名的分支都没有准备好进行审核,而其他分支已准备好进行审核.

在执行此操作时git fetch --all,我的git图(by /libexec/git-core/git-gui)将看到所有分支,无论它们是否具有下划线前缀.它使图表复杂化.

我想git fetch忽略那些_XXXX分支被下载到我的本地git.所以当我查看git图时,它就像:

• 可见分支: RemoteA/Branch1,RemoteB/Branch1,RemoteB/Branch2
• 忽略分支: RemoteA/_Branch2,RemoteB/_Branch3

我怎样才能做到这一点？

由于git fetch不进行任何更改，它只是更新引用并使跟踪分支与远程分支保持最新（就像它所说的是否领先和/或落后）。

我可以看出，了解远程仓库上发生的情况非常重要。

如果 git fetch 不是破坏性的。为什么 git 不只要有互联网连接就定期运行 git fetch ？

制作一个为我做这件事的脚本是个好习惯吗？

有时我在文章命令中看到：git pull -p
但我没有在官方文档中找到相关信息

这个选项是什么意思？

UPD

正如@torek 所指出的，该-p选项被传递给git fetch. 而-p在这里是指：

-p
--prune
在获取之前，删除远程上不再存在的任何远程跟踪引用。

但我不明白git-pull 企业是如何合作的git-fetch？
我如何才能弄清楚哪些git选项如何以及哪些选项从一个命令落到另一个命令？

git pull、 git fetch和之间有什么区别git rebase？我感觉pull和fetch是一样的。

我在 CI 盒子上运行测试。为了加快速度，我只是做了一个浅克隆：

git clone --depth 1 git@github.com:JoshCheek/some_repo.git

假设所有测试都通过，我想触发管道中的下一步。触发的内容取决于上次部署（参考d123456）和我刚刚测试的当前参考（参考c123456）之间更改的文件。如果我做了一个普通的克隆，我可以发现这样的结果：

git diff --name-only d123456 c123456

但我的克隆很浅，所以它不知道这些提交。我发现我可以用来git fetch --depth=n获取更多历史记录，但我只知道 SHA，而不知道 SHA 的深度。以下是可能可以回答这个问题的一组方法：

# hypothetical remote diff
git diff --name-only origin/d123456 origin/c123456

# hypothetical ref based fetch
git fetch --shallow-through d123456
git diff --name-only d123456 c123456

# hypothetical way to find the depth I need
depth=`git remote depth-to d123456`
git fetch --depth "$depth"
git diff --name-only d123456 c123456

否则，我似乎可能必须编写一个循环并继续调用，--deepen直到我的历史记录包含提交。这看起来很痛苦（意味着编写/维护很烦人）并且昂贵（意味着缓慢，请记住浅层克隆的目的是减少这种成本）。

所以，我知道你可以通过以下方式拉出一个分支而不检查它：

git fetch origin branchname:branchname

有没有办法在不检查的情况下也跟踪该分支？ （通常，这是通过：git checkout --track origin/branchname或来完成的git branch -u origin branchname）答案可以是完全独立的命令，也可以是上述获取的一部分。

我正在尝试$ git pull 或$ git fetch命令myRepo给我错误但myTestRepo工作正常。

命令给了我这个错误。

Fetching origin
fatal: unable to access 'http://mysite/myPath/myRepo.git/': Recv failure: Connection reset by peer
error: Could not fetch origin

我尝试了 git$ git fetch -p和$ git fetch -p --all -f命令，他们工作了一两次之后，命令给出了相同的错误。

从一个拉到下一个,git pull服务器上的每一个都以此结束:

$ git pull
remote: Counting objects: 53, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 32 (delta 19), reused 0 (delta 0)
Unpacking objects: 100% (32/32), done.
error: unable to find 71682baccff823caa21420b16dd231c6b9c1b133
fatal: object 71682baccff823caa21420b16dd231c6b9c1b133 not found

与...相同git fetch.我可以通过将文件复制.git/object/71/682baccff823caa21420b16dd231c6b9c1b133到服务器来解决这个问题,但是经过多次拉动后,错误仍然存​​在,每次都在分支上使用最新的提交对象.

怎么会发生这种情况？我该如何解决这个问题呢？

完整git clone不是一个好的解决方案,因为此存储库位于正在运行的服务器项目上,并且没有git控件的情况下有更多文件.

是否可以clone进入新目录,然后将.git目录复制到旧文件夹？或者没有触及目录还有其他解决方案吗？

看似随机，我们的本地存储库不再能够从Bonobo服务器获取。当我们尝试在本地获取时，最大的远程回购（大约4GB）会在不同的时间和不同的人发生。起初只是每隔几个月，但现在频率越来越高，并且今天同一时间发生了很多本地存储库。目前，我们正在通过移动工作.git文件夹来解决该问题。

它会快速打印一些POST git-upload-pack (gzip X to Y bytes)，然后挂半小时到一个小时。

如果我从对象目录中删除了一个打包文件，它会抱怨丢失的东西，然后开始正确地进行提取，但仅限于此git-upload-pack。

我已经尝试过repack并且gc以各种方式都没有效果。我尝试将服务器和客户端上的git从1.8.4升级到1.9。

cloneing也有同样的问题，但是升级Bonobo可以解决这个问题，即使它与git的版本相同。昨天一个新克隆的回购正在运行，但今天却存在相同的问题。

有趣的是，我们里面有很多dll和pdb。它已经使用了一年，并且是使用git-svn从SVN存储库中导入的。

这是痕迹

$ GIT_TRACE=1 git fetch -v
trace: built-in: git 'fetch' '-v'
trace: run_command: 'git-remote-https' 'origin' 'https://xxx
/yyy.git'
trace: run_command: '"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore
/git-credential-winstore.exe" get'
trace: run_command: '"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore
/git-credential-winstore.exe" store'
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
trace: run_command: 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--in
clude-tag' '--thin' 'https://xxx/yyy.git/'
trace: built-in: git 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--i …