We have had a big git repository that we have re-created under a new git url. The process was the following

• create new empty git repo
• copy paste the code from the old main branch, and commited it
• re-created some branches, lets call one of them feature/a (also with copy paste of files)
• developers started working on it

Now when the developers try to merge in their feature/a branch back into main it overwrites some parts of the code as it thinks the changes in the feature branch are newer, while in the old repository they were of course identified as older changes as the full git history was available.

Is there a way to solve this situation so the developers dont run into confusion once they start merging?

We have had a big git repository that we have re-created under a new git url. The process was the following

• create new empty git repo
• copy paste the code from the old main branch, and commited it
• re-created some branches, lets call one of them feature/a (also with copy paste of files)
• developers started working on it

Now when the developers try to merge in their feature/a branch back into main it overwrites some parts of the code as it thinks the changes in the feature branch are newer, while in the old repository they were of course identified as older changes as the full git history was available.

Is there a way to solve this situation so the developers dont run into confusion once they start merging?

• git
• git-merge
• git-history
• git-history-graph

• 2 It is important to understand what the commit graph is and what it means to merge to diverged histories. The way I understand what you did and what you got as result is a direct consequence that you disregarded the old commit history. At a minimum, you must recreate the project states at the merge bases (the commit where the main branch and the feature branches) diverged, then rebuild the history on those. – j6t Commented Jan 17 at 17:28

2 Answers 2

Say, you had this old history:

a--b--c--d--e--f--g     <-- main
         |\
         | h--i         <-- feature/h
          \
           k--l--m      <-- feature/k
            \
             n--o       <-- feature/n

In the following, I use capital letters to mean a commit whose project state is a copy of the corresponding lowercase letter commit above.

You did this in the new repository:

G          <-- main
|\
| I        <-- feature/h
|\
| M        <-- feature/k
 \
  O        <-- feature/n

Of course, when you now merge a feature into the main branch, all changes from, for example, G to I are considered to be merged, because that is how you set up the history.

What you actually should have done is include all merge bases in the reconstructed history:

D--G         <-- main
|\
| I          <-- feature/h
 \
   K--M      <-- feature/k
    \
     O       <-- feature/n

Now the merges should work as expected.

For each feature branch, rebase with the old repo's main branch, assuming that the last commit there is the one from which you took the copy (otherwise rebase with that commit), then copy-paste the code as before.

Now all the commits after that point are genuine changes and should merge just fine.

If you don't have the old repo and can't work with it, you can use git cherry-pick to reapply the commits you want to keep from the feature branch (in your new repo) to a new branch (also in your new repo).

If you just copy-pasted the code across along with the changes you don't want, and it's all bodged into one commit, and you have no access to the old repo, I'm afraid you're out of luck; you will have to choose which changes to apply manually.