From: Shourya Shukla <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH v2 1/1] gitfaq: append the 'Common Issues' section Date: Tue, 21 Apr 2020 14:08:20 +0530 [thread overview] Message-ID: <20200421083820.GB11800@konoha> (raw) In-Reply-To: <email@example.com> On 20/04 05:57, Junio C Hamano wrote: > Shourya Shukla <firstname.lastname@example.org> writes: > >+ 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. I understand. My words turn out to be very ambiguous sometimes. I meant creating a separate remote for fetch and separate one for push. Apologies for the confusion. > "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. Yep. I will add this. This reads out much better. > >+ 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. I thought it would be OK to describe a maybe *unorthodox* way to do this. I will remove it in the next version. > 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, ... That sounds quite better. I will incorporate this. Thank you so much for such a detailed review! :) Regards, Shourya Shukla
next prev parent reply other threads:[~2020-04-21 8:39 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 2020-04-21 8:38 ` Shourya Shukla [this message] 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200421083820.GB11800@konoha \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2 1/1] gitfaq: append the '\''Common Issues'\'' section' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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).