Reputation: 303
I already managed to merge branches from multiple GIT repositories into a single new repository (using a combination of "git filter-branch" and "git fetch/merge"). But I cannot seem to "merge" the tags from those branches...is this even possible ? As far as my (quite limited) GIT knownledge goes, a tag refers to a single commit that itself is identified by a SHA1 hash value that is basically calculated from all preceeding commits. Since branches from different repositories don't have a common ancestor commit, I find it hard to image how a tag could be rewritten in a way that it still "makes sense" (in the GIT way) in the context of a new and totally unrelated repository.
Any ideas ?
EDIT: To clarify what I intend to do:
Let's assume I have two repositories called "A" and "B" that I want to combine into a single new repository called "C".
The directory layout is something like
A | |-someFileA |-anotherFileA |-...
B | |-someFileB |-anotherFileB |-...
and the combined repository should look like
C | |-A | |-someFileA | |-anotherFileA | |-... | |-B | |-someFileB | |-anotherFileB | |-...
Upvotes: 4
Views: 316
Reputation: 53
If you want to waste a few hours on it, I did some similar weird repo management through python and dulwich. It's a one off hack, but if getting it done is worth a few hours or time, go for it.
Upvotes: -1
Reputation: 1325137
Tags are not directories (as they would in Subversion), so fetch/merge won't consider them.
Plus a git fetch doesn't fetch all tags by default (unless --tags
is specified).
Considering tags reference an immutable content, and that you are modifying that content through merges, I don't think you can easily preserve them, unless you reapply tags with similar name manually to commits that you deem similar to the original tagged ones.
Another less intrusive way to "combine" those two repos would be to declare A
and B
as submodules of C
.
No merge involved, and A
and B
keep theirs branches and tags
Upvotes: 2