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
next prev parent 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).