Re: How-to combine several separate git repos?

From: Wink Saville <wink@saville.com>
Date: Dec 9, 2007, 19:12 UTC
Message-ID: <475C3E25.30704@saville.com>
In-Reply-To: <20071209104336.GA3163@steel.home>

Alex Riesen wrote:

Show 11 quoted lines

> Wink Saville, Sun, Dec 09, 2007 07:34:01 +0100:
>   
>> I've got several git repositories of different projects and was thinking
>> I should combine into one repository, but my googling around didn't turn up
>> any simple way of doing it.
>>
>> Any advice?
>>     
>
> Should they both be visible in one working tree as directories?
>

Yes, I currently have:

  ~/prgs/android/StateMachine
  ~/prgs/android/test2
  ~/prgs/android/test-annotation

I'd with 3 git repo's in StateMachine, test2 & test-annotation. Ideally I was thinking having using submodules as they separate but related. But not sure submodules are ready.

Show 13 quoted lines

> Should these be independent branches?
>
> For instance, you can fetch one into another:
>
>     $ cd project1
>     $ git config remote.project2.url /path/to/project2
>     $ git config remote.project2.fetch 'refs/heads/*:refs/project2/*'
>     $ git fetch project
>
> That will give you two (or more) branches, containing history of the
> project1 and project2. They are still completely independent, just use
> the same object store.
>

So the above isn't what I want, but for grins I tried it, and got to this point:

wink@ic2d1:$ cd StateMachine
wink@ic2d1:$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
wink@ic2d1:$ git config remote.test2.url ../test2
wink@ic2d1:$ git config remote.test2.fetch 'refs/heads/*:refs/test2/*'
wink@ic2d1:$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "test2"]
        url = ../test2
        fetch = refs/heads/*:refs/test2/*
wink@ic2d1:$ git fetch test2
warning: no common commits
remote: Counting objects: 24, done.  
remote: Compressing objects: 100% remote: (16/16), done.  
remote: Total 24 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (24/24), done.  
 From ../test2
 * [new branch]      master -> refs/test2/master
wink@ic2d1:$ git checkout -b test2 test2/master
Branch test2 set up to track remote branch refs/test2/master.
Switched to a new branch "test2"
wink@ic2d1:$ git status
# On branch test2
nothing to commit (working directory clean)
wink@ic2d1:$ git status
# On branch test2
nothing to commit (working directory clean)
wink@ic2d1:$ git branch -a
  master
* test2
wink@ic2d1:$ git checkout master
Switched to branch "master"
wink@ic2d1:$ git checkout test2
Switched to branch "test2"

So that worked, but as I mentioned not quite what I want as I want to "see" them all simultaneously.

Show 5 quoted lines

> You can merge them, for example:
>
>     $ cd project1
>     $ git merge project2/master
>

Starting over (restoring the original from a tar backup) this didn't work I get:

wink@ic2d1:$ cd StateMachine wink@ic2d1:$ git merge ../test2/master ../test2/master - not something we can merge

Show 23 quoted lines

> Assuming that there is no filename collisions you'll get a repo with
> two merged histories (and two starting points). In case you get
> conflicts you can either resolve them by editing or just move the
> problematic project in subdirectory:
>
>     $ git merge -s ours --no-commit project2/master
>     Automatic merge went well; stopped before committing as requested
>
> here will be no conflicts. Merge strategy "ours" (-s ours) does not
> take anything from the branch to be merged. The coolest strategy ever.
> "--no-commit" stops the operation just before committing.
>
>     $ git read-tree --prefix=project2/ project2/master
>     $ git checkout-index -a
>     $ git commit
>
> That's it. The histories are merged and the files of project2 are
> placed in the directory "project2". It is a wee bit harder to browse
> the history of the files: you have to give both new and "old" name of
> the project2's files, as if you renamed them (that's what read-tree
> with --prefix did).
>
>

So the first suggestion works, but I don't want them as separate branches as I want to work on the simultaneously and they'll share common code.

Another option I was thinking would work for me would be to use submodules. But I'm not sure submodules are ready for neophytes and maybe it doesn't do what I want?

Thanks,

Wink Saville