开发者

how to change remove+add to move in git history

开发者 https://www.devze.com 2022-12-13 18:11 出处:网络
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 lo

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
   |  |  |_.开发者_C百科..
   |_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?


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.


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

0

精彩评论

暂无评论...
验证码 换一张
取 消