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

Subsystems: documentation, the rest

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:03:42

Dick [off-list ref] 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 <redacted>
---
 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

From: Eric Sunshine <hidden>
Date: 2016-06-15 23:03:42

On Thu, Jan 29, 2015 at 3:26 PM, Junio C Hamano [off-list ref] 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 <redacted>
---
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help