告诉git遵循移动的内容（而不是简单的移动文件） [英] Telling git to follow moved content (not simply moved files)

问题描述

重构源代码时，有时需要将大块文本移动到文件中，甚至移动到新文件中。你创建一个分支重构并提交：

  $ git checkout master 
 $ git分支重构
 $ git checkout重构
<移动代码> 
 $ git commit -m重构代码
  

然而，旧的pre-refactor分支，改变被移动的代码：

  $ git checkout master 
< change code在分支上的其他地方移动了重构> 
 $ git commit -mbugfix
  

在分支重构，然后您想要包含在 master 中进行的更改：

  $ git checkout重构
 $ git merge master 
<巨人合并冲突> 
  

这会导致大的合并冲突。如果有一种方法可以告诉git内容是简单地移动的，应该可以自动合并。

更糟糕的是，即使解决了冲突并提交后，git仍然无法使用分辨率来进一步合并：

 <修正冲突> 
 $ git commit -mmerge master into renfactored
 $ git checkout master 
< change more code> 
 $ git commit -mbugfix2
 $ git checkout重构
 $ git merge master 
<另一个巨型合并冲突> 
  

这是否可以避免？我试过 git rerere ，它无法解决这里的冲突。有没有什么办法可以让git将文本块移动为实际移动，而不是删除和插入？如果不能，那么如果你需要保留两个并行分支一段时间，最好的办法是减少合并冲突？

虽然这对于<移动完整文件的内容，我找不到关于只移动部分的信息，或移动到同一个文件中。

另外，如果有解决方案，那会是什么 git blame 对重构的
代码的行为？它指向重构提交还是忽略它？有没有办法实现后来？

如果有人感兴趣，我已经把我使用的（非常小）存储库的base64编码tar.gz用于在pastebin上测试

潜在的解决方案

一个潜在的解决方案可能是通过应用（自动）编辑的补丁与预重构分支中的更改来执行合并。有没有开发软件来做到这一点？使用这种方法我猜想，因为这对git是透明的，所以 git blame 会指向重构提交。

我发现同样的问题，应用于差异。没有提及任何现有的非专有实现，但是提到了一种跟踪块运动的算法。

不幸的是，据我所知，可以替换内置的git合并策略。这意味着你不能停止冲突，但你可以使用智能工具来解决它们。

这一个 Semantic Merge 看起来很有趣，它也可以是

While refactoring source code, sometimes you need to move big blocks of text inside a file, or even to a new file. You create a branch refactored and commit away:

$git checkout master
$git branch refactored
$git checkout refactored
<move code around>
$git commit -m "refactored code"

However, people may commit on top of the old pre-refactor branch, changing the code that was moved:

$git checkout master
<change code that was moved elsewhere on branch refactored>
$git commit -m "bugfix"

On branch refactored, you then want to incorporate changes made in master:

$git checkout refactored
$git merge master
<giant merge conflict>

This leads to a large merge conflict. If there was a way to tell git that the content was simply moved, it should be possible to merge automatically.

The worse part is that, even after resolving the conflict and commiting it, git still can't use the resolution to figure out further merges:

<fix conflicts>
$git commit -m "merge master into refactored"
$git checkout master
<change more code>
$git commit -m "bugfix2"
$git checkout refactored
$git merge master
<another giant merge conflict>

Is this avoidable at all? I've tried git rerere and it can't resolve the conflicts here. Is there any way git can see moving a block of text as a actual move, instead of a deletion and insertion? If it can't, what's the best approach to minimizing merge conflicts, if you need to keep the two parallel branches for a while?

While this is easy enough for moving the contents of a complete file, I couldn't find information on moving only part of it, or moving inside the same file.

Also, if there's a solution for this, what would be the behaviour of git blame on the refactored code? Would it point to the refactoring commit, or ignore it? Is there a way to achieve the later?

In case anyone's interested, I've put a base64 encoded tar.gz of the (very minimal) repository I'm using for testing on pastebin

Potential Solutions

One potential solution might be performing the merge by applying a (automatically) edited patch with the changes in the pre-refactored branch. Is there software developed to do this? Using this approach I guess that, since this is transparent to git, git blame would point to the refactoring commit.

I've found the same question, applied to diff. There's no mention to any existing non-proprietary implementation, but there mention to a algorithm that tracks block movement

解决方案

Unfortunately you can't replace the built in git merge strategies as far as I can tell. This means you can't stop the conflicts, however you can use an intelligent tool to resolve them.

This one Semantic Merge looks interesting, it can also be used by git

这篇关于告诉git遵循移动的内容（而不是简单的移动文件）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！