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.
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.
2 Likes
Humbling. There is much of git that is over my head.
I would be tempted to do pull requests from one to the other.
1 Like
@James_Hibbard 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.
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.
https://www.screencast.com/t/6cGbX6v2wcGp
So then I tried it without the flag
https://www.screencast.com/t/w7wDEpeyWJ
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.
1 Like
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.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.