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
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:
> 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?
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 email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at