git 无法从 HEAD 历史中确定上游 SVN 信息
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/1269566/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Unable to determine upstream SVN information from HEAD history
提问by Chad
Why do I get this error message?
为什么我会收到此错误消息?
采纳答案by bstpierre
(Posted Chad's "question" as an answer, fixed formatting and typos.)
(张贴乍得的“问题”作为答案,修复了格式和拼写错误。)
There are a couple of causes for this error message.
此错误消息有几个原因。
The first, being the most common. You have two disjoint histories in your git repository: The history that you made in git, and the history from the remote svn repository.
第一种,最常见。您的 git 存储库中有两个不相交的历史记录:您在 git 中创建的历史记录,以及来自远程 svn 存储库的历史记录。
To fix this, you need to make your git repository and svn repository share one common ancestor so git can figure what commits have changed what.
要解决此问题,您需要让 git 存储库和 svn 存储库共享一个共同的祖先,以便 git 可以确定哪些提交更改了哪些内容。
The following Article, discusses how to fix the problem:
以下文章讨论了如何解决此问题:
The second possible cause of the problem is if you have an early version of git (possible, windows msysGit package) and you have just created a new git repository that communicates with a remote svn repository.
问题的第二个可能原因是,如果您有一个早期版本的 git(可能,windows msysGit 包)并且您刚刚创建了一个与远程 svn 存储库通信的新 git 存储库。
For example:
例如:
git svn init svn://svn.xxx.xxx/xxx/trunk
git svn fetch -r BASE:10
or
或者
git clone svn://svn.xxx.xxx/xxx/trunk // Adds all the files in the revision...
And you get the follow error messages, when using the following commands.
使用以下命令时,您会收到以下错误消息。
git svn info
Unable to determine upstream svn information from working tree or
无法从工作树中确定上游 svn 信息或
git svn rebase
unable determine upstream svn information working tree history or
无法确定上游 svn 信息工作树历史或
git svn dcommit
Unable to determine upstream SVN information from HEAD history
无法从 HEAD 历史中确定上游 SVN 信息
If you get the above error messages, first step is to check your git version. If your running a older git version <= 1.6.3.3.* that was in my case with (msysGit), then the easiest way to fix the problem is to update to a newest version of git such as 1.6.4.*.
如果您收到上述错误消息,第一步是检查您的 git 版本。如果您运行的是较旧的 git 版本 <= 1.6.3.3.*,就我而言是 (msysGit),那么解决问题的最简单方法是更新到最新版本的 git,例如 1.6.4.*。
The following Articlediscusses the problem in more detail.
下面的文章更详细地讨论了这个问题。
回答by slafs
i got this message because of cloning the svn repo with --no-metadata
option. Maybe that's the case with Your problem too.
我收到此消息是因为使用--no-metadata
选项克隆了 svn 存储库。也许你的问题也是如此。
When cloning it without that option everything is fine.
在没有该选项的情况下克隆它时,一切都很好。
The --no-metadata
option is meant to clone an SVN repository when the new git
clone is to be come the canonical source in the future. It lacks the capacity to commit back to the SVN upstream, because it has no way to track differences between the git clone and the SVN upstream.
该--no-metadata
选项旨在在新git
克隆将来成为规范源时克隆 SVN 存储库。它缺乏提交回 SVN 上游的能力,因为它无法跟踪 git clone 和 SVN 上游之间的差异。
回答by axel22
In my case, the HEAD from the svn repo should have been matched to the HEAD from the git repo. Thisshould solve the problem:
就我而言,svn repo 中的 HEAD 应该与 git repo 中的 HEAD 匹配。这应该可以解决问题:
git update-ref refs/remotes/git-svn refs/remotes/origin/master
If your use a different git branch for svn trunk, for example svntrunk
, that branch should be referenced instead, that is:
例如svntrunk
,如果您对 svn 主干使用不同的 git 分支,则应改为引用该分支,即:
git update-ref refs/remotes/git-svn refs/remotes/origin/svntrunk
回答by Ed Ruder
I got this message after I incorrectly added the -s
/--stdlayout
parameter to the git svn clone
command for a Subversion repo that did nothave the "standard Subversion layout" of trunk
, tags
, and branches
relative paths.
我得到这个消息后,我错误地添加的-s
/--stdlayout
参数的git svn clone
命令为没有一个Subversion回购不具有“标准的Subversion布局”的trunk
,tags
和branches
相对路径。
(The Subversion repos I usually clone do have the standard relative paths, so when I cloned a Subversion repo that didn't have them using my usual git svn clone
command, I got this cryptic message. The message is 100% correct, but almost 100% useless when trying to figure out what the problem is.)
(我通常克隆的 Subversion 存储库确实具有标准的相对路径,因此当我使用我常用的git svn clone
命令克隆没有它们的 Subversion 存储库时,我收到了这条神秘消息。该消息 100% 正确,但几乎 100% 没用当试图找出问题所在时。)
回答by mohammadthalif
You may also get this error, when you have checkout freshly created SVN repo.
当您结帐新创建的 SVN 存储库时,您也可能会收到此错误。
I have solved this by
我已经解决了这个问题
- First doing an initial commit via svn command
- Then clone the repo using git svn command.
- 首先通过 svn 命令进行初始提交
- 然后使用 git svn 命令克隆 repo。
回答by andrej
got same problem, here is solution based on http://eikke.com/importing-a-git-tree-into-a-subversion-repository/article:
遇到同样的问题,这里是基于http://eikke.com/importing-a-git-tree-into-a-subversion-repository/文章的解决方案:
$ git svn init http://server.com/svn/project/trunk/prototypes/proto1/
$ git svn fetch
W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/svn/!svn/bc/100/dcom/trunk/prototypes/ws' path not found
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
This may take a while on large repositories
r147367 = 37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d (refs/remotes/git-svn)
$ svn log http://server.com/svn/project/trunk/prototypes/proto1/
------------------------------------------------------------------------
r147367 | user | 2014-01-16 18:02:43 +0100 (Thu, 16 Jan 2014) | 1 line
proto1 home
------------------------------------------------------------------------
$ git log --pretty=oneline master | tail -n1
71ceab2f4776089ddbc882b8636aacec1ba5e832 Creating template
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #1
$ git show-ref git-svn
37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d refs/remotes/git-svn
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #2
$ echo "71ceab2f4776089ddbc882b8636aacec1ba5e832 37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d" >> .git/info/grafts
$ git svn dcommit
Committing to http://server.com/svn/project/trunk/prototypes/proto1 ...
A README.md
A pom.xml
A src/main/java/.gitkeep
A src/main/resources/.gitkeep
A src/main/webapp/WEB-INF/web.xml
A src/main/webapp/index.html
A webapps/.gitkeep
Committed r147419
A README.md
A pom.xml
A src/main/java/.gitkeep
A src/main/resources/.gitkeep
A src/main/webapp/WEB-INF/web.xml
A src/main/webapp/index.html
A webapps/.gitkeep
r147419 = 6a8bda7262739306d0a6e17eaad2802737dedc35 (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
Unstaged changes after reset:
M pom.xml
M src/main/webapp/index.html
A .gitignore
Committed r147420
M pom.xml
M src/main/webapp/index.html
A .gitignore
r147420 = 749b5acec55c341672bca08d07de8c336b5a4701 (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
...etc...
回答by Daniel Hershcovich
Another cause for this problem is a wrong svn-remote.svn.rewriteRoot
option (see this answerfor instructions on using this).
此问题的另一个原因是错误的svn-remote.svn.rewriteRoot
选项(有关使用说明,请参阅此答案)。
The git-svn-id
line in your commits imported from Subversion has to match the rewriteRoot
URL if it is set.
如果设置git-svn-id
了rewriteRoot
URL,则从 Subversion 导入的提交中的行必须与URL匹配。
回答by Nathan Kidd
I got this message because I used a FQDN for the git svn init
command but the pre-existing git-svn integration was using just the hostname.
我收到这条消息是因为我在git svn init
命令中使用了 FQDN,但是预先存在的 git-svn 集成只使用了主机名。
E.g. grep git-svn-id
showed:
例如grep git-svn-id
显示:
git-svn-id: svn://host/repo/...
But I did:
但我做到了:
git svn init -Ttrunk svn://host.domain.com/repo
(We have a machine that regularly syncs a git repo with svn, then everyone else has git config --add remote.origin.fetch refs/remotes/*:refs/remotes/*
to fetch down the svn synced branches.)
(我们有一台机器会定期将 git repo 与 svn 同步,然后其他所有人都必须git config --add remote.origin.fetch refs/remotes/*:refs/remotes/*
获取 svn 同步的分支。)
回答by ka3ak
It happened to me too. And I don't remember to have done something unusual. SVN repo existed, Git version was the most recent. There were 2 commits in local git repo that I wanted to commit to SVN. But when I ran:
它也发生在我身上。我不记得做过什么不寻常的事情。SVN repo 存在,Git 版本是最新的。我想提交给 SVN 的本地 git 存储库中有 2 个提交。但是当我跑:
git svn dcommit
I got the error.
我得到了错误。
git svn fetch
and
和
git svn rebase
didn't help. I got the same error after running them.
没有帮助。运行它们后我得到了同样的错误。
I think the problem could be caused by the fact that I did a squash of 2 local git commits previously. If it was the reason I still don't understand why a squash is a problem in this case (If you know, please, comment it).
我认为这个问题可能是由于我之前对 2 个本地 git 提交进行了压缩。如果这是我仍然不明白为什么在这种情况下壁球有问题的原因(如果您知道,请发表评论)。
Anyway I solved the problem by cloning the svn repo again to another working directory.
无论如何,我通过再次将 svn repo 克隆到另一个工作目录来解决了这个问题。
git svn clone .../trunk
Added the problematic git repo as a remote one:
添加有问题的 git repo 作为远程仓库:
git remote add last /cygdrive/c/data/problem_repo
and did a cherry-pick on all the commits that weren't yet moved to SVN. After that I could successfuly run:
并对所有尚未转移到 SVN 的提交进行了挑选。之后我可以成功运行:
git svn dcommit
回答by szager
Another possible cause: If you have an svn-remote..rewriteUUID config set, git-svn may have trouble locating the right meta-data for the repository. For example, you might have something like this (see the git-svn man page for a discussion of why you would want to do this):
另一个可能的原因:如果您有一个 svn-remote..rewriteUUID 配置集,git-svn 可能无法为存储库定位正确的元数据。例如,您可能有这样的事情(有关为什么要这样做的讨论,请参阅 git-svn 手册页):
[svn-remote "svn"]
url = svn://read-write.test.org
fetch = trunk/project:refs/remotes/trunk
rewriteRoot = http://read-only.test.org/svn
rewriteUUID = 1234-abcd
... where 1234-abcd is the UUID of the read-only mirror. When you 'git svn fetch', you might end up with this file:
... 其中 1234-abcd 是只读镜像的 UUID。当你 'git svn fetch' 时,你可能会得到这个文件:
.git/svn/refs/remotes/trunk/.rev_map.5678-dcba
... where 56780-dcba is the UUID of the read-write repository. The fix is to:
... 其中 56780-dcba 是读写存储库的 UUID。解决方法是:
$ mv .git/svn/refs/remotes/trunk/.rev_map.5678-dcba \
.git/svn/refs/remotes/trunk/.rev_map.1234-abcd
Can't say for certain whether that is a durable solution, i.e., it might get confused next time you 'git svn fetch'. Might try a symlink rather than 'mv', I haven't experimented with that.
不能确定这是否是一个持久的解决方案,即,下次您 'git svn fetch' 时它可能会感到困惑。可能会尝试使用符号链接而不是“mv”,我还没有尝试过。