how do I merge completely unrelated repositories ?

Hi,

I'd like to create a new empty repository and merge into it 2 completely unrelated remote repositories.

How would you do it, since merge will not merge if it cannot find a common ancestor ?

On Thu, Jun 26, 2008 at 11:39:37AM +0200, Christian MICHON <christian.michon@gmail.com> wrote:

Did you try so?

If there are no conflicting paths then a simple

git pull /path/to/other/repo.git master

or similar should work.

On Thu, Jun 26, 2008 at 11:45 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:

yes I did. it was failing.

pull = fetch + merge

maybe I was not fetching the objects properly.

your hint works fine. thanks!

I was starting considering rebasing the 2 repos on a common empty commit (that would have been desperate)...

Hi,

On Thu, 26 Jun 2008, Miklos Vajna wrote:

FWIW this is how gitk got into git.git... See 5569bf9b(Do a cross-project merge of Paul Mackerras' gitk visualizer). This also was often referred to as the "coolest merge ever".

Ciao, Dscho

On Thu, Jun 26, 2008 at 12:25:54PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

If we are at it, that's not unique, there are other root commits as
well: 2744b23 - git-tools, 161332a - gitweb, cb07fc2 - git-gui, 16d6b8a
- p4-fast-export. ;-)

Hi,

since a similar question burdens my soul for quite some time, I would like to take the opportunity to extend the question a bit:

I have around 10 CVS repositories, each with around 5 modules. This has developed over time, and now I want to combine them all into a single Git repository, with a new directory structure introduced.

One possibility would be to convert these 50 CVS modules into git repositories, then for each of these git repositories introduce the new tree structure (that is, what is relevant for this part), move all files to their new location (via "git mv"), and finally pull everything in into the common repository.

This is all fine, except of the inability to follow the history nicely (for example, via gitk I will only see the history from the point on where in those temporary git-repositories the files have been moved to their new place).

To avoid this break in the history, it would be great if cvsimport could already move the files to the right place in the directory hierarchy, that is, if an additional parameter P could be given, the initial path, and files will be imported as P/file. Then I could import everything right away into the final git repository, without problems with clashes. I can't find something like that in the documentation.

Is there perhaps some other possibility? It seems easiest to me to do this little bit of surgery at the time of the import, before git gets into his troubles with hash-values.

thanks!

Oliver

On Thu, Jun 26, 2008 at 12:25:54PM +0100, Johannes Schindelin wrote:

On Thu, 26 Jun 2008, Oliver Kullmann wrote:

I had a similar desire with git-svn; instead, what I do is a git-filter-branch that renames all the files in the repository.

man git-filter-branch gives you one way to do that; I basically re-invented that due to not scrolling all the way to the bottom, and run it every night on the git-svn repo since I want my everything-renamed repo to be kept as an up-to-date mirror of the svn repo.

That's my idea for you.

-- Asheesh.

Oliver,
  I wrote a little (314 line) perl script to blend multiple cvsps output
streams together before handing them to git-cvsimport, it seems to work
fine.  It should (but I haven't tested it) even still allow the
incremental approach.

Not sure if I should just attach it here (it's not that big, but still), but if you need/want a copy of "cvsps_blender.pl", just send me an email and I'll send it out....

-Kelly

Christian MICHON wrote:

The problem probably is _empty_ repository (what do you want to merge), not lack of common ancestors. git.git repository has joined unrelated projects (git-mail-tools, gitweb, gitk, git-gui) and it has several roots, and even a few separate branches.