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 


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.


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.

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 

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 
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 

Hope the above made sense. I did a minor attempt and it seemed to work for 

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


Reply via email to