Git - Merge one repo into another?


#1

Long story short here, we have our code base in a repository. Let's call it "RepoA". I have a "RepoB" that contains just some files that, ideally, upon RepoA/B merging, RepoB will override RepoA's files. How can I merge RepoB/master into RepoA/somerandombranch ? Let me know if you guys need additional information. I have googled it but it's just populating with information about how to clone repositories, not merge two together.


#2

Not something I've had to do myself, but it seems this is what you are trying to do:

The answer that seems most straight-forward is not the accepted answer, rather this one: https://stackoverflow.com/a/10548919/1136887

I would also (shameful as it is to admit it), create a copy of both repos before getitng to work.


#3

Humbling. There is much of git that is over my head.

I would be tempted to do pull requests from one to the other.


#4

@Pullo is this something that can be repeated? I want both RepoA/B to both still exist. I just want a copy of RepoB to be merged into RepoA. E.g. this needs to be something that I can create 100 branches on RepoA, and each branch could theoretically have RepoB/master copy merged in for each.


#5

Thanks!

cd path/to/project-b
git remote add project-a path/to/project-a
git fetch project-a
git merge --allow-unrelated-histories project-a/master # or whichever branch you want to merge
git remote remove project-a

On the git merge command, the --allow-unrelated-histories failed.


So then I tried it without the flag

I have merge conflicts now. Ideally anything within RepoB/master (what's being pulled into RepoA/whatever) will override any merge conflicts.

I would do a PR Mitt, but this needs to be a repeatable process. Something that I can do with many many branches.


#6

I don't know your exact circumstance but the need to repeat this over and over seems like flawed logic to me. It seems like the best solution would be to merge repo B (target) into A (destination) . Once you resolve all conflicts and stabilize A freeze B. Going forward restrict work to A. After A is stabilized I don't see any reason why you would need to continue work on B. Everyone doing work should work from A using a methodology like gitflow with branching not individual repos.


#7

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.