Dick <dick@xxxxxxx> writes:
> rm -rf left/ right/ right.git/
> git init left
> cd left/
> echo "hello world" > test.txt
> git add test.txt
> git commit -m .
> cd ..
> git clone --bare left right.git
> git clone right.git/ right
> cd right
> git remote set-url origin ../left
> git remote set-url origin --push ../right.git
This is not using "origin" and set-url correctly. Even though you
can use physically different URLs for fetching from and pushing
into, the named repository 'origin' is still conceptually the same
repository. You use this mechanism when you want to fetch over the
public git:// protocol (which is lighter-weight) while pushing into
the same repository over ssh:// protocol (which may be heavier and
requires authentication). The important part of the equation is
that the data should go to and come from the same place. What you
pushed to 'origin', if you fetch from 'origin' again, should come
back to you.
And that is not what your two calls to set-url are doing.
In a triangular workflow to fetch from somewhere while pushing into
somewhere else, you are using _two_ different repositories: your
upstream's repository you fetch from, and your own repository you
push to publish your result. So you would use _two_ remotes, not a
single 'origin'.
The 'right' person, who follows the 'left' developer who publishes
the more authoritative work in 'left.git' for you and others to
fetch from, and publishes his work to 'right.git' to ask 'left' to
pull, would do something like:
git init --bare right.git
git clone left right
cd right
git remote add mine ../right.git
git config remote.pushDefault mine
git push --all;# to publish to ../right.git
to set things up. Then
edit && git commit && git other-commands && ...
git push ;# updates ../right.git
to publish his work. Updating from 'left' would go like this:
# pretend 'left' did something
( cd ../left && git commit --allow-empty -m empty )
git pull ;# or 'git pull --rebase'
--
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