Maybe I can also help shed some light here.
I'll start with the difference between "patch" and "commit". Patch is -- 
simply put -- a diff between two versions of the same tree. You can only 
apply the patch to the same version of the tree from which it was 
generated. Period.
In comes git to add a new dimension to patching: the history. A patch with 
a history is a "commit". Every commit has a SHA1 that makes it unique. Two 
commits that have different SHA1s are viewed as different commits, even 
though running "git format-patch" on both could yield identical results! 
otherwise put, even though it's the same patch, if applied to different 
histories, you have different commits. And this is the case with your A and 
B reposes. Even though B starts fresh from a given commit in A, git has no 
way of knowing this without replicating the entire history (I'm not an 
expert here, so someone may cut in and contradict me; but this highlights 
the true git-related question behind your question: "Is there a way to link 
two separate git histories without actually replicating them?"). There 
simply is no way to cherry-pick commits (or rebase branches) from B into A, 
since git has no way to know that they are even the same source tree, let 
alone have any common history among them.
So, the way I see it, in your case you have but one choice, and that is to 
move patches from B to A (and backwards, if A is indeed active itself!) and 
applying them in the same sequence. Git also tries to make this easier for 
you by providing things like format-patch, send-email, apply, etc.

Anyone else please feel free to disagree.

joi, 24 mai 2012, 18:40:52 UTC+3, 7ff a scris:
> Hello,
> I would appreciate some help or suggetions on this problem:
> condensed version:
> -----------------------------
> A) a "big" repository with long history and a submodule
> B) a "small" repo made recently from an export of repo A, except some 
> files/folders and including the files from the submodule of A
> how can I merge new commits (or cherrypick)?
> more detailed:
> -----------------------
> repo A is a project with about 10 years of history (partially imported 
> form svn) which I want to keep. This repo includes files for different 
> customers/ applications.
> Recently, I agreed to work on this project with a team of one customer in 
> a shared git repository. Obviously, they must not be able to see private 
> files belonging to other customers. And there was no need for them to see 
> my 10ys of history.
> So for a quick start, I just created a new repository with the files to be 
> used. And to make things simpler (maybe more complicated now) I included 
> the files from the submodule.
> Now I want to link the two repos so that I can merge new commits between 
> the two repos. 
> (git remote starts with a "no common history" warning ... so maybe some 
> merge -s ours magic should be applied ... ? But the difference in 
> submodules makes me doubt that this will be easy)
> To be sure not to import private object into B, merging one way B into A 
> alone would be a helpful start. Ideally, I would to able to merge both ways.
> Is this possible at all? Or should I prepare to juggle with patch files?
> Thanks,
> Matt

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to