git fetch失败"refs/remotes/origin/pr/34跟踪两者" [英] git fetch failed "refs/remotes/origin/pr/34 tracks both"

查看:653
本文介绍了git fetch失败"refs/remotes/origin/pr/34跟踪两者"的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是git的新手,但是我对git fetch感到困惑(我在TFS和SVN上有更多经验,因此欢迎类比:)

I am new to git and I am stuck on a git fetch (I have more experience on TFS & SVN, so any analogy is welcome :)

所以我在Github上找到了一个我分叉的项目:

So I found a project on Github that I forked :

  • source project (Xposed Tinted StatusBar)
  • mine is here

我进行了一些签入,还进行了git pull来从源中获取最新的更改,有时,我想我按下了Synchronize按钮(我正在使用AndroidStudio BTW),但我从这里迷路了

I made a few check-in, also made a git pull to fetch latest changes from the source and at some point, I think I hit the Synchronize button (I'm using the AndroidStudio BTW) and I got lost from here.

它生成了我没有的 commit 真的很了解,从这里开始,我似乎无法再从源中获取最新添加的内容(黑源的最后4个更改)

It generated this commit that I don't really understand and from here, it seems that I am not able to fetch latest additions from source anymore (the 4 last changes on black source)

我在git fetch上遇到以下错误:

I am getting the following error on git fetch :

致命的:refs/remotes/origin/pr/34跟踪refs/pull/34/head和 refs/heads/pr/34

fatal: refs/remotes/origin/pr/34 tracks both refs/pull/34/head and refs/heads/pr/34

https://github.com/MohammadAG/Xposed-Tinted-Status -酒吧/网络

谢谢

推荐答案

简短版本:远程上名为pr/34的分支成为您的origin/pr/34.但是,远程服务器上名为refs/pull/34/head的引用也将成为您的origin/pr/34.但是他们不能两者都成为那样,所以git抱怨并退出了.设置分支映射的任何方法都不能与在github上设置请求请求分支的方法完美地结合在一起(但是我对这两个软件一无所知).

Short version: the branch named pr/34 on the remote, becomes your origin/pr/34. But the ref named refs/pull/34/head on the remote, also becomes your origin/pr/34. But they can't both become that, so git complains and quits. Whatever is setting up the branch mapping is not playing well with whatever is setting up the pull-request branches on github (but I don't know anything about those two pieces of software).

删除+refs/pull/*/head:refs/remotes/origin/pr/* fetch配置行可能(我不知道)是合理的.或者,您可以将它们映射到其他本地引用名称空间,例如refs/pullreqs/origin/*(但是键入此类引用名称有些不便).如果每个请求都将在github上同时创建 refs/heads/pr/number refs/pull/number/head,我将删除一条配置行.

It may (I don't know) be reasonable to delete the +refs/pull/*/head:refs/remotes/origin/pr/* fetch configuration line. Alternatively, you could map these to some other local ref-name-space, such as refs/pullreqs/origin/* (but such a reference name is somewhat inconvenient to type in). If every pull request is going to create both refs/heads/pr/number and refs/pull/number/head on github, I'd go ahead and remove the one configuration line.

对问题根源的详细说明如下.鉴于此:

Longer explanation of source of problem follows. Given this:

+refs/pull/*/head:refs/remotes/origin/pr/*
+refs/heads/*:refs/remotes/origin/*
+refs/heads/*:refs/remotes/origin/*

作为git config --get-all remote.origin.fetch的输出,我可以解释出了什么问题. 如何解决"取决于您想要的结果.

as output from git config --get-all remote.origin.fetch, I can explain what's going wrong. "How to fix it" depends on the results you want.

这里的每条输出行都是一个"refspec",它由三部分组成:+:左侧的名称和:右侧的名称.两个名称中都可以使用一个*,并且它的工作方式(但不完全是)类似于*在文件名(例如*.c*.py等)中匹配,而第二个*使用第一个*匹配的内容.无论如何,下面应该很明显.

Each output line here is a "refspec", which consists of three parts: the +, a name on the left of the :, and a name on the right of the :. One * is allowed in both names, and it works sort of (but not exactly) like * matching in file-names, e.g., *.c, *.py, etc., with the second * then using whatever the first * matched. It should be obvious below, anyway.

(最后一行是多余的,因此无害,它只会使匹配发生两次.)

(The last line is redundant and thus harmless, it just makes the match happen twice.)

所以,让我们看看上面的引用名称refs/pull/34/headrefs/heads/pr/34的含义,这两个名称都存在于名为origin的远程服务器上(在github上).

So, let's see what the above means for the ref-names refs/pull/34/head and refs/heads/pr/34, both of which are present in the remote named origin (on github).

对于refs/pull/34/head:这仅匹配第一个refspec. *部分与34匹配.该refspec的右侧说要重写为读取refs/remotes/origin/pr/*,因此结果是:

For refs/pull/34/head: this matches just the first refspec. The * part matches the 34. The right-hand-side of that refspec says to rewrite this to read refs/remotes/origin/pr/*, so the result is:

refs/remotes/origin/pr/34

现在让我们来解决refs/heads/pr/34.这与第一个refspec不匹配,但与第二个refspec匹配. *部分与pr/34匹配.该refspec的右侧表示将其重写为refs/remotes/origin/*,因此结果是:

Now let's tackle refs/heads/pr/34. This does not match the first refspec, but it does match the second. The * part matches pr/34. The right-hand-side of that refspec says to rewrite it as refs/remotes/origin/*, so the result is:

refs/remotes/origin/pr/34

请注意origin上的两个不同名称如何映射到本地存储库中的同一 final 名称.如origin所示,Git不知道是否将本地refs/remotes/origin/pr/34设置为等于第一个或第二个.

Note how two different names on origin have mapped to the same final name in your local repository. Git does not know whether to set your local refs/remotes/origin/pr/34 equal to the first one, or the second one, as seen on origin.

要使错误消失,必须完全丢弃不需要的额外"匹配项,或者更改重写规则,以使两个不同的远程refs/whatever成为两个不同本地 s.这意味着您需要更改git配置文件中的fetch =行.

To make the error go away, you must either discard the unwanted "extra" match entirely, or change the rewriting rules so that the two different remote refs/whatevers become two different local refs/remotes/origin/whatevers. That means you need to change the fetch = lines in your git config file.

我不知道您想要什么结果,所以我无法说出如何重写它们. (而且,我首先不知道是什么创建了这些内容,普通的git clone仅创建了一个+refs/heads/*:refs/remotes/origin/*条目.其他添加了冗余条目,而另一个添加了refs/pull/*/head条目.坏了,再加上在github上创建了refs/heads/pr/34的事实.)

I don't know what result you want, so I can't say how to rewrite them. (And, I don't know what created these in the first place—a normal git clone creates just one +refs/heads/*:refs/remotes/origin/* entry. Something else added the redundant entry, and the one for refs/pull/*/head. It's that something-else that broke things. Well, that, plus the fact that something created refs/heads/pr/34 on github.)

这篇关于git fetch失败"refs/remotes/origin/pr/34跟踪两者"的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆