list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Shourya Shukla <>
Subject: Re: [PATCH v2 1/1] gitfaq: append the 'Common Issues' section
Date: Mon, 20 Apr 2020 17:57:17 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Shourya Shukla's message of "Mon, 13 Apr 2020 19:39:18 +0530")

Shourya Shukla <> writes:

>+ [[changing-remote-of-the-repository]]
>+ I want to change the remote of my repository. How do I do that?::

>+ 	A remote is an identifier for a location to which Git pushes
>+ 	your changes as well as fetches any new changes(if
>+ 	any).

You push changes to a repository.
You fetch changes from a repository.

Hence, "a location, which you push changes to, as well as fetch new
changes from, if any."  But a lot more people fetch from repositories
than push to repositories, so "a location, which you fetch changes from,
as well as push your changes to." may be easier to follow by audiences.

In any case there is one crucial and precious thing in what you
wrote here.  A remote is a name for *A* location, even if you have
two URLs (i.e. one used for fetching from, and another used for
pushing to).  They are to name logically the same place, only the
way you reach may be different.  For example, you may have an
unauthenticated https:// URL for fetching, while the URL you use to
the repository may be ssh:// URL.  But the important point is that
these URLs are about the same repository---if you push over ssh://
URL your changes, you would be able to see the changes over https://
URL that you use for fetching.

>+      There might be different circumstances in which one
>+ 	might need to change the remote:


>+ 		1. One might want to update the url of their remote;
>+ 		in that case, the command to use is, `git remote
>+ 		set-url <name> <newurl>`.

Yes, this truly is "changing" the old one by replacing its old URL
with a new URL.

>+ 		2. One might want to have two different remotes for
>+ 		fetching and pushing; this generally happens in case
>+ 		of triangular workflows.  In this case, it is
>+ 		advisable to create a separate remote just for
>+ 		fetching/pushing.

Yes, by definition, triangular is about fetching from somebody else
and publishing to your own place for others to fetch, so you'd need
two remotes, as you are not talking with a single repository.

But I find your phrasing quite confusing.

"advisable to have two remotes, one for fetching and the other for
pushing" would probably be a lot more correct.

And I can understand why you did not write so, and instead ended up
with your version.  In order to reach the goal of having two (one
for push and one for fetch), you would "create a separate remote" as
you are likely to already have one for one direction (in other
words, you didn't want to say "advisable to create two remotes").

You wrote "create a separate remote just for fetching/pushing" and
made the direction of the new one vague, because you do not know if
that existing one is for fetching or pushing,

But I suspect that all of the above would not be as clear to those
who need their questions answered as to somebody like me who knows
what you want to say already.  And you do not want to explain things
in a way that only is understood by experts.  How about rephrasing
the above more like so?

	2. One may want to fetch from one repository and push to
	anther repository---this is often called a "triangular"
	workflow.  As you'd probably have one remote that you use
	for fetching already created when you cloned the project,
	you would want to create a separate remote to record the URL
	you push to.

>+ But, another way can be to change
>+ 		the push url using the `--push` option in the `git
>+ 		set-url` command.

Do not recommend this when you describe a triangular workflow; it is
confusing to readers.  Keeping separate fetch and push URLs for a
single remote is not triangular.  

Describe it separately as a different use case, e.g.

	3. You may want to push to a repository over a network
	protocol different from the one you use to fetch from the
	repository.  Perhaps you want unauthenticated https:// URL
	for fetching from, and use ssh:// URL when you push to, the
	same remote.  In such a case, ...

Other than the above nits I picked, overall it is a good idea to
raise this question in the FAQ, I would think.


  parent reply	other threads:[~2020-04-21  0:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 14:09 [PATCH v2 0/1] update gitfaq Shourya Shukla
2020-04-13 14:09 ` [PATCH v2 1/1] gitfaq: append the 'Common Issues' section Shourya Shukla
2020-04-14  1:06   ` brian m. carlson
2020-04-14  7:33   ` Junio C Hamano
2020-04-16 19:05   ` Junio C Hamano
2020-04-21  6:58     ` Shourya Shukla
2020-04-16 19:36   ` Junio C Hamano
2020-04-21  0:57   ` Junio C Hamano [this message]
2020-04-21  8:38     ` Shourya Shukla
2020-04-21 18:00       ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2020-04-13 10:55 [PATCH v2 0/1] update gitfaq Shourya Shukla
2020-04-13 10:55 ` [PATCH v2 1/1] gitfaq: append the 'Common Issues' section Shourya Shukla

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 1/1] gitfaq: append the '\''Common Issues'\'' section' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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 read-only IMAP folder(s) and NNTP newsgroup(s).