git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wink Saville <wink@saville.com>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: How-to combine several separate git repos?
Date: Sun, 09 Dec 2007 11:12:37 -0800	[thread overview]
Message-ID: <475C3E25.30704@saville.com> (raw)
In-Reply-To: <20071209104336.GA3163@steel.home>

Alex Riesen wrote:
> 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.
> 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.

> 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

> 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

  reply	other threads:[~2007-12-09 19:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-09  6:34 How-to combine several separate git repos? Wink Saville
2007-12-09 10:43 ` Alex Riesen
2007-12-09 19:12   ` Wink Saville [this message]
2007-12-09 19:55     ` Daniel Barkalow
2007-12-09 23:44       ` Wink Saville
2007-12-10  1:11         ` Daniel Barkalow
2007-12-10  2:29           ` Wink Saville
2007-12-10  3:01             ` Daniel Barkalow
2007-12-10  6:36               ` Wink Saville
2007-12-10  6:51                 ` Daniel Barkalow
2007-12-10  7:01                   ` Wink Saville
2007-12-10  7:52     ` Alex Riesen
2007-12-10 17:55       ` Wink Saville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=475C3E25.30704@saville.com \
    --to=wink@saville.com \
    --cc=git@vger.kernel.org \
    --cc=raa.lkml@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).