如何更改删除+添加以在 git 历史记录中移动

发布于 2024-08-13 10:14:16 字数 561 浏览 4 评论 0原文

我有一个 git 存储库,它是一些旧的 svn 存储库的混合体。当我混合所有内容时,我没有意识到要执行 git mv 而不是仅仅移动文件,所以现在大多数文件的 svn 历史记录都丢失了。有办法解决这个问题吗?

旧的结构是这样的:

svn1
|_apps/
|_tests/
|_...

svn2
|_src
|_libs

svn3
|_src
|_libs

现在:

   root
   |_libs
   |  |_svn1_name
   |  |  |_apps
   |  |  |_tests
   |  |  |_...
   |_addons
   |  |  |_svn2_name
   |  |  |  |_src
   |  |  |  |_libs
   |  |  |_svn3_name
   |  |  |  |_src
   |  |  |  |_libs

我尝试签出之前对该 mv 的提交,执行 git mv,创建一个新分支并重新调整 master 的基础,但结构有点复杂,合并很痛苦。有没有更简单的方法来做到这一点?

i have a git repository that is a mix of some old svn repos. when i mixed everything i didn't realized to do git mv instead of just moving the files so now the svn history for most of the files is lost. is there a way of fixing this?

the old structure was something like:

svn1
|_apps/
|_tests/
|_...

svn2
|_src
|_libs

svn3
|_src
|_libs

and now:

   root
   |_libs
   |  |_svn1_name
   |  |  |_apps
   |  |  |_tests
   |  |  |_...
   |_addons
   |  |  |_svn2_name
   |  |  |  |_src
   |  |  |  |_libs
   |  |  |_svn3_name
   |  |  |  |_src
   |  |  |  |_libs

i've tried doing checkout to the previous commit to this mv, doing git mv, creating a new branch and rebasing master against that but the structure is kind of complex and the merge is a pain. is there an easier way to do this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

悲凉≈ 2024-08-20 10:14:16

通常,Git 跟踪重命名与删除和添加没有任何不同。当这种情况发生在同一个提交中时,Git 可以快速推断重命名已完成,并在 git log 中适当地显示重命名。但是,如果同一文件的删除和添加发生在不同的提交中,那么您需要使用 git 日志

--更难查找副本

<块引用>

出于性能原因,默认情况下,仅当副本的原始文件在同一变更集中被修改时,-C 选项才会查找副本。此标志使命令检查未修改的文件作为副本源的候选文件。对于大型项目来说,这是一个非常昂贵的操作,因此请谨慎使用。提供多个 -C 选项具有相同的效果。

Normally, Git doesn't track a rename any differently than a delete and an add. When this happens within the same commit, Git can quickly infer that a rename was done and show the rename appropriately in git log. However, if the delete and add of the same file happen in different commits, then you need to use the --find-copies-harder switch of git log:

--find-copies-harder

For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command inspect unmodified files as candidates for the source of copy. This is a very expensive operation for large projects, so use it with caution. Giving more than one -C option has the same effect.

匿名的好友 2024-08-20 10:14:16

使用 git log --follow 处理单个文件,除了作为添加+删除提交的重命名之外,我还可以跟踪其历史记录

using git log --follow on a single file I can track its history beyond renames that were committed as add+remove

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文