Wink Saville, Sun, Dec 09, 2007 20:12:37 +0100:
>> 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
This is *not* what I suggested. It should be:
$ git config ... (as suggested before)
$ git fetch test2
$ git merge test2/master
Here test2/master - is *NOT* a path. It is the name of the branch
where the local repository stores reference to the commit
corresponding to the master of remote repo (that is: the "master"
branch of "test2", as seen from the repository where you do the
merge).
> 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.
Sound like the secode (merge) approach
> 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?
They are ready for some (dunno if they'd like to be called neophytes).
I just don't think you need them (keywords on your explanations being
"share common code", understanding them as "the modules use the common
code simultaneously").
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
