Take the 2-minute tour ×

Say I have function X in file A, and I wanted to move that function to file B. In the meantime, somebody else made changes to function X in file A.

Does git do anything special when merging those two changes? Would it recognize the same function was moved to file B and apply the changes there? Or would we end up losing the changes or having two copies of the same function in file A and B?

Most of the articles I found about moving code in git refer mostly to renaming whole files and not blocks of code inside files. The closest I found is a blurb from Linus at kerneltrap:

And when using git, the whole 'keep code movement separate from changes' has an even more fundamental reason: git can track code movement (again, whether moving a whole file or just a function between files), and doing a 'git blame -C' will actually follow code movement between files. It does that by similarity analysis, but it does mean that if you both move the code and change it at the same time, git cannot see that 'oh, that function came originally from that other file', and now you get worse annotations about where code actually originated.

So it seems like git will recognize that the code was moved somewhere else, but doesn't really say what happens during a merge.

share|improve this question

4 Answers 4

up vote 5 down vote accepted

No, git won't do this level of change. It will notice when you move an entire file; so, for example, if you moved the file, deleted everything else in it, then it might stand a chance of picking up the changes. But it doesn't do a change on a per-subfile or any kind of refactoring.

share|improve this answer
so if I'm merging the changes to X in A into my branch where I moved X to B, I'd basically lose those changes because Git thinks I deleted those lines? I guess I just need to carefully look at the diffs then ... –  jtjin Dec 13 '09 at 21:21
You won't lose them: you'll have to merge the conflict by hand. –  Greg Bacon Dec 13 '09 at 21:42

I don't think the previous answer is correct in the general case, because git doesn't really care about files - the file name is used as the basis for some heuristics, but the way git thinks about content isn't centred entirely around the idea of a file. Unlike other VCSs, git tracks content, and in this case the content happens to have moved, but it's the same content.

As a result, git should be able to handle merges between branches even where files have been renamed, or code move between files, so depending on what exactly you've done, it will probably handle the merge fine.

As long as the changes to X don't cause a merge conflict (which could happen if you'd changed both the original version and the renamed version), the fact that X has been moved to B shouldn't matter, and the merge result should contain the result of both changes. If there is a problem, it would indicate that git hasn't correctly tracked the code movement.

In practice, the previous answer is probably based on personal experience when the detection machinery failed, in which case https://git.wiki.kernel.org/index.php/GitFaq#How_to_manually_resolve_conflicts_when_Git_failed_to_detect_rename.3F may be helpful.

share|improve this answer

I think AlBlue is correct, not Nye.

In my simple test, git was not able to automatically merge two branches where one branch inserted a line into a function, and the other moved that function to a new location in the same file. git is not tracking chunks of content smaller than the file, it seems.

To resolve the merge conflict, the person doing the merge would have to be aware of how the two changes worked and how they should be combined.

See also git merge: apply changes to code that moved to a different file

share|improve this answer

I think the real situation is much more complex, but from what I have experienced, git can handle this kind merge in three merge well.

For example:

One function of a File in branch A was moved to another location in the same file and at the meantime create a branch B to hold it. The difference between branch B and branch A is only the code location change in the same file.

Branch C changed that function.

So, if you do,

git rb --onto B A C

It will automatically merge the change from branch C to the new location of that function in branch B.

share|improve this answer

Your Answer


