* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow @ 2015-01-28 19:49 Dick 2015-01-29 17:27 ` Chris Packham 2015-01-29 19:31 ` Junio C Hamano 0 siblings, 2 replies; 7+ messages in thread From: Dick @ 2015-01-28 19:49 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow 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 1 sibling, 1 reply; 7+ messages in thread From: Chris Packham @ 2015-01-29 17:27 UTC (permalink / raw) To: Dick; +Cc: GIT 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow 2015-01-29 17:27 ` Chris Packham @ 2015-01-29 18:08 ` Chris Packham 0 siblings, 0 replies; 7+ messages in thread From: Chris Packham @ 2015-01-29 18:08 UTC (permalink / raw) To: Dick; +Cc: GIT 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow 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 19:31 ` Junio C Hamano 2015-01-29 19:59 ` Dick 1 sibling, 1 reply; 7+ messages in thread From: Junio C Hamano @ 2015-01-29 19:31 UTC (permalink / raw) To: Dick; +Cc: git 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' ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git loses commits on git pull --rebase with Dictator and Lieutenants Workflow 2015-01-29 19:31 ` Junio C Hamano @ 2015-01-29 19:59 ` Dick 2015-01-29 20:26 ` Re* " Junio C Hamano 0 siblings, 1 reply; 7+ messages in thread From: Dick @ 2015-01-29 19:59 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow 2015-01-29 19:59 ` Dick @ 2015-01-29 20:26 ` Junio C Hamano 2015-01-29 20:58 ` Eric Sunshine 0 siblings, 1 reply; 7+ messages in thread From: Junio C Hamano @ 2015-01-29 20:26 UTC (permalink / raw) To: git; +Cc: Dick 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':: ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Re* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow 2015-01-29 20:26 ` Re* " Junio C Hamano @ 2015-01-29 20:58 ` Eric Sunshine 0 siblings, 0 replies; 7+ messages in thread From: Eric Sunshine @ 2015-01-29 20:58 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List, Dick 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> > --- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-29 20:58 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2015-01-29 19:59 ` Dick 2015-01-29 20:26 ` Re* " Junio C Hamano 2015-01-29 20:58 ` Eric Sunshine
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.