CODEWITHSUNDEEP
git
Stephen
Stephen

Reputation: 471

How can I get git to treat two identically named files from different branches as separate files?

I have two different git branches: master and feature. In master, we have created a class in a file called "Upgrade". In feature, we have also created a class called "Upgrade", but unfortunately it has different functionality to the other upgrade class. This was not discovered until I'd merged the branches.

I would like to be able to tell git to treat the two different classes as separate classes in separate files.

i.e.

rename Upgrade(master) -> Upgrade01
rename Upgrade(feature) -> Upgrade02

Is there a way of doing this?

Upvotes: 0

Views: 52

Answers (1)

torek
torek

Reputation: 487993

If I can take the liberty of rephrasing the question, it amounts to this:

Branches X and Y share a common history (a merge base commit B, specifically) in which file F did not exist. In some commit after B on branch X, a file F was created. In some commit after B on branch Y, a different file F was also created. Now, when on branch X, doing git merge Y, I get a merge conflict that says F was created on both branches. Can I get git merge to pretend that instead of creating F in X, we created F_X, and instead of creating F in Y, we created F_Y?

The short answer is no, but there are two straightforward ways to handle it:

  1. Abort the merge (git merge --abort). On branch X, create a new commit in which you move F to F_X. On branch Y, create a new commit in which you move F to F_Y. Make any other appropriate changes along the way—these two commits give you the opportunity to test everything separately in each branch. Then, merge the two branches as before; this time there is no "same file created" conflict.

  2. Continue the merge by checking out F from the tip of branch X but (re)naming it F_X, and checking out F from the tip of branch Y but (re)naming it F_Y:

    $ git checkout HEAD -- F; git mv F F_X
$ git checkout MERGE_HEAD -- F; git mv F F_Y

    (note that you can use any other way to name the branch tip commits, such as the branch names X and Y instead of HEAD and MERGE_HEAD; and note that doing the git checkout here will resolve the merge conflict in the index). You may also have to make other changes as needed, as you would have done with method (1).

    When done with whatever changes are needed, commit the merge as usual.

    The drawback to this method—the reason I'd prefer method (1) if possible—is that the resulting merge has a significant change from both "input sides". This makes it more difficult to track down (e.g., bisect) bugs, should the merge later prove faulty. If you make the two sets of changes in the two branches instead, and then merge, you can track the bug to one more-specific change—e.g., perhaps the bug is only in the change made to Branch Y—which could make "future you" much happier.

Upvotes: 1

Related Questions