git svn - < file>未在提交< hash>中找到 [英] git svn - <file> was not found in commit <hash>

查看:102
本文介绍了git svn - < file>未在提交< hash>中找到的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在用git-svn下拉一个(相当大的)svn repo的过程中,我遇到了下面的错误信息(用真实信息代替了通用信息):

In the middle of pulling down a (rather large) svn repo with git-svn, I encountered the following error message (generic info substituted for real info):

Found possible branch point: svn://server/project/trunk/dir => svn://server/project/branches/branchname, <revision>
Initializing parent: refs/remotes/branchname@<revision>
project/trunk/dir/file was not found in commit <hash> (r<revision>)

我已阅读其他帖子,可以通过一些修改来取消这个信息。然而,我宁愿不失去历史,尽可能无痛地前进。

I have read in other posts that it is possible to "un-fetch" this info through some tinkering. However, I would rather not lose the history and go forward as painlessly as possible.

我怎样才能得到 git-svn fetch 继续?

推荐答案

这可能意味着您正在接收一个新的svn修订版,原因)不存在于您的git commit等价于父svn修订版本中。导致这种情况的一个非常简单的方法是与 - ignore-paths 不一致(最初没有办法配置它们,并且必须在每个 git-svn 可能会获取的命令行)。另一种方式是让svn服务器端的某个人以更改存储库权限的方式,以便整个子树文件突然出现(从您的角度来看)您的git存储库没有历史记录。

This probably means that you are receiving a new svn revision which modifies a file which (for some reason) does not exist in your git commit equivalent of the parent svn revision. One very easy way to cause this is to be inconsistent with --ignore-paths (originally there was no way to configure those and they had to be entered on every git-svn command line that might fetch). Another way is for someone on the svn server end to change repository permissions in such a way that a whole subtree of files suddenly appears (from your perspective) that your git repository has no history for.

最简单的方法是通过 - ignore-paths git-svn fetch c $ c>(或者更好的是 svn-remote.svn.ignore-paths config条目)来忽略树的问题部分。你可以使用命令行参数来传递一个修订版本,并且不会再出现问题,除非有人在svn端修改它。

The easiest way to get past this immediate problem and continue git-svn fetch is to use --ignore-paths (or better the svn-remote.svn.ignore-paths config entry) to ignore the problem part of the tree. You can get away with the command line argument to pass a single revision and you won't hit the problem again until someone modifies it on the svn side.

如果你想要在没有 - ignore-paths 的情况下恢复,那么您将需要修复父修订版,以便它包含要修改的文件。我特意写了 git-svn reset 来引用更少的修补程序。它可以将您的svn remote重置回真正创建文件的位置,以便将其整合到您的历史记录中。这不会消灭你的工作副本,但你需要在这个新的历史记录上重新分配任何工作分支。

If you want to recover without --ignore-paths then you will need to fix the parent revision so that it includes the file being modified. I wrote git-svn reset specifically to do the "un-fetch" you refer to with less tinkering. It can reset your svn remote back to where the file was really created so you can integrate it into your history. This won't wipe out your working copies, but you will need to reparent any working branches on this new history.

这篇关于git svn - &lt; file&gt;未在提交&lt; hash&gt;中找到的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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