0

At the start of the project we had a single repository with our solution in. Someone, based on a requirement to create another instance of the solution with a few 'branding' changes, made the decision to copy the solution in its current state and push it into a completely separate repository. Subsequently someone else did the same thing again.

We are now in the situation where we have three separate solutions sitting in three separate repositories all with very similar code. Copy paste refactoring has been high.

I want to pull all three back together so that we can make changes that will apply across a single code base and be deployed to separate environments (with config managed through DI, etc.).

I have tried what has been outlined to move all the separate repos into sub folders in a new repository based on the steps here: Merge two Git repositories without breaking file history

What I am finding is that the first repository merge works fine and I can put the code happily into its own subfolder, the second merge from the second repo I receive conflict merges when running the equivalent of git merge old_b/master

I think that this is because they effectively share the same origin (for want of a better word), based on when they were originally copied.

Is this assumption correct? How can I get around it to have a single repo?

Community
  • 1
  • 1
DShorty
  • 582
  • 1
  • 6
  • 14
  • What exactly did you do so far (which commands did you execute)? Frankly, I don't see where subfolders enter, here. – AnoE Aug 02 '16 at 11:55
  • It's hard to see the problem here. You've got 3 repositories with common ancestry, so to reign them all back into one, simply add remotes pointing to each other and then handle merging branch management as usual. Sub folders don't make sense to me. Your merge command listed doesn't indicate a sub folder, but a normal conflict in project root. Ultimately, I think you're wanting to maintain independent branches in a repo pointing to their respective forks. Don't try to merge if they're truly divergent apps, just cherry-pick the common boilerplate stuff. – Jeff Puckett Aug 02 '16 at 12:15
  • My thinking was for put them into separate sub folders in a single repository while I work at pulling out common code into another shared project within the same repo. I liked the subfolder approach as it combines everything into single repository but maintains existing separtion while we work on shared code in a measured way. I believe 3 years worth of changes and copy paste reuse will make cherry picking a pain. – DShorty Aug 02 '16 at 12:26
  • Commands already run in linked article up to second repo merge. Line with command 'git merge old_b/master'. Doing this on a test repo to see impact. Cc @AnoE – DShorty Aug 02 '16 at 12:33
  • Well, this sounds different than the original quesion, it looks like you don't really want to do a merge in the `git merge` sense, but a complete code overhaul, cherry-picking stuff from everywhere. Is that closer to it? – AnoE Aug 02 '16 at 12:39
  • End result I'm after is to combine 3 repositories into 1, where the contents of the original 3 sit in sub directories in the new repo to keep current state. Also even though they share some anicestory from when they were originally duplicted its doesn't impact the subfolder versions. Perhaps there is a better way to achieve my desired outcome. – DShorty Aug 02 '16 at 12:45

0 Answers0