git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Dick <dick@mrns.nl>
Cc: git@vger.kernel.org
Subject: Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow
Date: Thu, 29 Jan 2015 11:31:14 -0800	[thread overview]
Message-ID: <xmqqlhkle64d.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <loom.20150128T203924-608@post.gmane.org> (dick@mrns.nl's message of "Wed, 28 Jan 2015 19:49:02 +0000 (UTC)")

Dick <dick@mrns.nl> 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'

  parent reply	other threads:[~2015-01-29 19:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 19:49 git loses commits on git pull --rebase with Dictator and Lieutenants Workflow Dick
2015-01-29 17:27 ` Chris Packham
2015-01-29 18:08   ` Chris Packham
2015-01-29 19:31 ` Junio C Hamano [this message]
2015-01-29 19:59   ` Dick
2015-01-29 20:26     ` Re* " Junio C Hamano
2015-01-29 20:58       ` Eric Sunshine

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=xmqqlhkle64d.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dick@mrns.nl \
    --cc=git@vger.kernel.org \
    /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).