Git责怪重组的SVN仓库 [英] Git blame on reorganized SVN repository

查看:176
本文介绍了Git责怪重组的SVN仓库的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



>我使用git-svn来访问SVN存储库。 SVN仓库曾经有一个包含大量文件夹树的结构来保存许多项目。去年,我重新整理了布局,并将其变为更标准的主干/标签/分支布局。其结果是,存储库中的所有文件都在2010年5月17日移动。



使用来自Eclipse的subclipse SVN客户端,我可以执行Team- >显示注释,它显示了我所期望的文件历史记录 - 2009年更改的代码行正确注释了author / date / checkin注释。



<但是,我使用git-svn克隆的git存储库上的 git blame 并不是那么有用。对于2010年5月17日之前修改的所有代码行,注释是:me / date 17th May 2010 / commentreorganizing repository ...。

我假设信息仍然存在,有没有办法让 git blame 来显示它?我非常推测地尝试了 git blame -C -C -C ... 没有成功。

解决方案

你确定旧提交出现在git仓库中吗?也许你的svn重组对于git-svn来说太大了。在5月17日之前找到svn修订版,然后 git svn find-rev r12345 找到相应的git哈希,如果有的话一。如果你告诉git-svn你的repo使用了'standard'trunk / trunk,分支/标签布局,它可能无法理解其他布局。您可能需要分两个阶段重做git-svn导入:一个用于旧布局,然后再用于新布局。你可以使用-r参数来实现这一点,以git svn fetch来只读取给定范围的修订。


git blame isn't showing me the all history of a SVN repository which had its layout reorganized.

I'm using git-svn to access a SVN repository. The SVN repository used to have a structure with a vast tree of folders to hold the many projects. Last year I reorganized and flattened the layout into a more standard trunk/tags/branches layout. The result of which is that all the files in the repository were moved on 17th May 2010.

Using the subclipse SVN client from Eclipse, I can do Team->Show Annotation and it shows the history of a file as I expect - lines of code changed in 2009 are correctly annoted with the author / date / checkin comment.

However, git blame on the git repository I've cloned using git-svn isn't so useful. For all lines of code modified before 17th May 2010, the annotation is: me / date 17th May 2010 / comment "reorganizing repository...".

I'm presuming the information is still there, is there way to get git blame to display it? I very speculatively tried git blame -C -C -C... without success.

解决方案

Are you sure the older commits appear in the git repo at all? Perhaps your svn reorganization was too big for git-svn to follow. Find the svn revision before the 17th May move, then git svn find-rev r12345 with that number to find the corresponding git hash, if there is one. Then git checkout that hash and see if the files you're interested in are in it.

If you told git-svn that your repo used the 'standard' trunk/branches/tags layout, it probably can't understand the other layout. You might need to redo the git-svn import in two stages: one for your old layout, and then again for your new layout. You can achieve this using the -r argument to git svn fetch to only fetch a given range of revisions.

这篇关于Git责怪重组的SVN仓库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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