git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Dick]

Hi all,

I've encountered a problem with the Dictator and Lieutenants Workflow. I've 
configured remote origin so it pulls from the "blessed repository" and 
pushes to the "developer public" repository.

When the "blessed repository" has the same branch name as the "developer 
public" repository git pull seems to drop commits.

I've create a test script to demonstrate, left is the blessed repository, 
right.git is the developer public and right is the developer private 
repository.

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
echo "bye world" >> test.txt 
git commit -a -m .
git push
git log
echo "start: two commits, ok"
git fetch
git rebase origin/master
git log
echo "manual fetch/rebase: two commits, still ok"
git pull --rebase
git log
echo "pull: one commits, oops?"

Am I using git wrong or is this a git bug?

Thanks for having a look!

Dick

Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Chris Packham]

Hi,

On Thu, Jan 29, 2015 at 8:49 AM, Dick <dick@mrns.nl> wrote:
> Hi all,
>
> I've encountered a problem with the Dictator and Lieutenants Workflow. I've
> configured remote origin so it pulls from the "blessed repository" and
> pushes to the "developer public" repository.
>
> When the "blessed repository" has the same branch name as the "developer
> public" repository git pull seems to drop commits.
>
> I've create a test script to demonstrate, left is the blessed repository,
> right.git is the developer public and right is the developer private
> repository.
>
> 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
> echo "bye world" >> test.txt
> git commit -a -m .
> git push
> git log
> echo "start: two commits, ok"
> git fetch
> git rebase origin/master
> git log
> echo "manual fetch/rebase: two commits, still ok"
> git pull --rebase
> git log
> echo "pull: one commits, oops?"
>
> Am I using git wrong or is this a git bug?
>
> Thanks for having a look!
>
> Dick

I can confirm the behaviour that Dick is seeing with git 2.0.4
(happens to be what I was running on my laptop). Just rebuilding
2.3.0-rc2 now.

AFAIK 'git fetch && git rebase origin/master' and 'git pull -r' in the
scenario above should be roughly equivalent.

I'll see if I can work the testcase above into an actual test script.

Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Chris Packham]

On Fri, Jan 30, 2015 at 6:27 AM, Chris Packham <judge.packham@gmail.com> wrote:
> Hi,
>
> On Thu, Jan 29, 2015 at 8:49 AM, Dick <dick@mrns.nl> wrote:
>> Hi all,
>>
>> I've encountered a problem with the Dictator and Lieutenants Workflow. I've
>> configured remote origin so it pulls from the "blessed repository" and
>> pushes to the "developer public" repository.
>>
>> When the "blessed repository" has the same branch name as the "developer
>> public" repository git pull seems to drop commits.
>>
>> I've create a test script to demonstrate, left is the blessed repository,
>> right.git is the developer public and right is the developer private
>> repository.
>>
>> 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
>> echo "bye world" >> test.txt
>> git commit -a -m .
>> git push
>> git log
>> echo "start: two commits, ok"
>> git fetch
>> git rebase origin/master
>> git log
>> echo "manual fetch/rebase: two commits, still ok"
>> git pull --rebase
>> git log
>> echo "pull: one commits, oops?"
>>
>> Am I using git wrong or is this a git bug?
>>
>> Thanks for having a look!
>>
>> Dick
>
> I can confirm the behaviour that Dick is seeing with git 2.0.4
> (happens to be what I was running on my laptop). Just rebuilding
> 2.3.0-rc2 now.

Also happens on 2.3.0-rc2

>
> AFAIK 'git fetch && git rebase origin/master' and 'git pull -r' in the
> scenario above should be roughly equivalent.
>
> I'll see if I can work the testcase above into an actual test script.

Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Junio C Hamano]

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'

Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Dick]

Thanks Junio! I should use git config remote.pushDefault thanks for pointing 
me in the right direction.

I guess the git remote set-url --push command should contain some warning 
about this.

gr
Dick

Re* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Junio C Hamano]

Dick <dick@mrns.nl> writes:

> I guess the git remote set-url --push command should contain some warning 
> about this.

Perhaps something like this would be good enough for a starter.

-- >8 --
Subject: Documentation/git-remote.txt: stress that set-url is not for triangular

It seems to be a common mistake to try using a single remote
(e.g. 'origin') to fetch from one place (i.e. upstream) while
pushing to another (i.e. your publishing point).  That will never
work satisfactory.  Think about what refs/remotes/origin/* would
mean in such a world---it fundamentally cannot reflect the reality.
If it follows the state of your upstream, it cannot match what you
have published, and vice versa.

Some low-quality websites may be spreading misinformation.  Let's
counter them by adding a few words to our documentation.

 - The description was referring to <oldurl> and <newurl>, but never
   mentioned <name> argument you give from the command line.  By
   mentioning "remote <name>", stress the fact that it is configuring
   a single remote.

 - Add a reminder that explicitly states that this is about a single
   remote, which the triangular workflow is not about.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-remote.txt | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index cb103c8..a77607b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -130,17 +130,25 @@ branches, adds to that list.
 
 'set-url'::
 
-Changes URL remote points to. Sets first URL remote points to matching
+Changes URLs for the remote. Sets first URL for remote <name> that matches
 regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If
-<oldurl> doesn't match any URL, error occurs and nothing is changed.
+<oldurl> doesn't match any URL, an error occurs and nothing is changed.
 +
 With '--push', push URLs are manipulated instead of fetch URLs.
 +
-With '--add', instead of changing some URL, new URL is added.
+With '--add', instead of changing existing URLs, new URL is added.
 +
-With '--delete', instead of changing some URL, all URLs matching
-regex <url> are deleted. Trying to delete all non-push URLs is an
-error.
+With '--delete', instead of changing existing URLs, all URLs matching
+regex <url> are deleted for remote <name>.  Trying to delete all
+non-push URLs is an error.
++
+Note that the push URL and the fetch URL, even though they can
+be set differently, must still refer to the same place.  What you
+pushed to the push URL should be what you would see if you
+immediately fetched from the fetch URL.  If you are trying to
+fetch from one place (e.g. your upstream) and push to another (e.g.
+your publishing repository), use two separate remotes.
+
 
 'show'::
 

Re: Re* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow

[Eric Sunshine]

On Thu, Jan 29, 2015 at 3:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Subject: Documentation/git-remote.txt: stress that set-url is not for triangular
>
> It seems to be a common mistake to try using a single remote
> (e.g. 'origin') to fetch from one place (i.e. upstream) while
> pushing to another (i.e. your publishing point).  That will never
> work satisfactory.  Think about what refs/remotes/origin/* would

s/satisfactory/satisfactorily/

> mean in such a world---it fundamentally cannot reflect the reality.
> If it follows the state of your upstream, it cannot match what you
> have published, and vice versa.
>
> Some low-quality websites may be spreading misinformation.  Let's
> counter them by adding a few words to our documentation.
>
>  - The description was referring to <oldurl> and <newurl>, but never
>    mentioned <name> argument you give from the command line.  By
>    mentioning "remote <name>", stress the fact that it is configuring
>    a single remote.
>
>  - Add a reminder that explicitly states that this is about a single
>    remote, which the triangular workflow is not about.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---