Do you mean that you have a "distribution repository" (without a working directory) and you want to add to it what is in a non-master branch in another git-managed directory (i.e. it has a "working directory" with the files). Have you looked to see if submodules or subtrees will do what you want?
http://git-scm.com/book/en/Git-Tools-Submodules <quote> It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other. Here’s an example. Suppose you’re developing a web site and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate. </quote> http://git-scm.com/book/ch6-7.html <quote> Now that you’ve seen the difficulties of the submodule system, let’s look at an alternate way to solve the same problem. When Git merges, it looks at what it has to merge together and then chooses an appropriate merging strategy to use. If you’re merging two branches, Git uses a *recursive*strategy. If you’re merging more than two branches, Git picks the *octopus* strategy. These strategies are automatically chosen for you because the recursive strategy can handle complex three-way merge situations — for example, more than one common ancestor — but it can only handle merging two branches. The octopus merge can handle multiple branches but is more cautious to avoid difficult conflicts, so it’s chosen as the default strategy if you’re trying to merge more than two branches. </quote> If you really, really want to keep the sources separate, like a "fork" of a project, then you might be able to do this into the "working directory", then git merge, then git push to the distribution repository. Something like: cd working-directory-which-has-new-files #contains the files to add git remote add move-to working-directory-to-receive-new-files/.git #.git subdirectory of working-directory to get files git checkout branch-with-files #checkout the branch which has the files to add git push move-to branch-with-file #push the branch to the repository needing the new files git remote rm move-to #get rid of the just added remote cd working-directory-to-get-new-files #go to the receiving working directory git merge branch-with-files #merge the new files in git push #and push the working directory to the distribution repository (if any) Hope the above made sense. I did a minor attempt and it seemed to work for me. On Sunday, December 9, 2012 6:31:53 AM UTC-6, Michael wrote: > > Hello, > > Sounds like a common scenario? We've decoupled some functionality from one > repo solution, and I'd like to promote that repo branch to another repo > master. Can this be done easily from a Git perspective, or do we just need > to copy the projects and other files into the newly cloned repo? > > Thanks... > > Regards, > > Michael > --
