Wink Saville, Sun, Dec 09, 2007 20:12:37 +0100:
quoted text
>> 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).

quoted text
> 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

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html