git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

From
Peter Wu <peter@lekensteyn.nl>
Date
Nov 25, 2014, 11:43 UTC
Message-ID
<2050939.TNKsWtkNmu@al>
In-Reply-To
<CAPc5daWh4hnKsTMpaW-TvCmVDfU+rzCezrAHcLgXDG6RVvzXHA@mail.gmail.com>
On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:
> On Mon, Nov 24, 2014 at 9:01 PM, Jeff King <peff@peff.net> wrote:
> > We could also stop making push fall back to fetch. But I think people
> > would find that irritating.

The common case is probably having the same fetch and push URL, so I think that this should not be changed.

Show 21 quoted lines
> > I dunno. I think there has always been an implicit "subordinate"
> > relationship between fetch and push URLs, with fetch being the "main"
> > one. Maybe that is so ingrained in me at this point that I do not see a
> > problem with the asymmetry.
> 
> I actually do not have problem with asymmetry/subordinate
> relationship myself, but then why are we adding --fetch to
> complement --push in the first place?
> 
> Or perhaps I am misunderstanding the suggested semantics
> of --both. That "subordinate" relationship really means that
> remote.nick.URL is the one that is used for both directions
> when pushURL is not set.
> 
> I misunderstood that --both would add identical value to both
> remote.nick.URL and remote.nick.pushURL, but that would
> break the implicit subordinate relationship. Is the suggested
> semantics of "set-url --both" to first delete remote.nick.pushURL
> if exists and then to set remote.nick.URL?
> 
> If that is what is being proposed, then I think it makes sense.

Yes, your last understanding is correct. For this feature, try to think as the user who does not know about the configuration implementation. That is why the --fetch option was proposed, earlier it did not make sense to me why a --push option exists, but a --fetch option is missing.

Option '--both' will drop the push URL and result in an implicit fallback to the fetch URL. It becomes slightly more hairy in the presence of URL sets (using --add and --delete), but I have also tried to make that act sensibly).

-- 
Kind regards,
Peter
https://lekensteyn.nl
Previous: Junio C Hamano
Message 27 of 27 in “remote: add new --fetch option for set-url”
  1. Peter WuNov 19, 2014
  2. Jeff KingNov 19, 2014
  3. Peter WuNov 19, 2014
  4. Jeff KingNov 19, 2014
  5. Peter WuNov 19, 2014
  6. Junio C HamanoNov 19, 2014
  7. Peter WuNov 19, 2014
  8. Junio C HamanoNov 19, 2014
  9. Junio C HamanoNov 19, 2014
  10. Junio C HamanoNov 19, 2014
  11. Peter WuNov 19, 2014
  12. Peter WuNov 24, 2014
  13. Junio C HamanoNov 24, 2014
  14. Peter WuNov 24, 2014
  15. Jeff KingNov 24, 2014
  16. Peter WuNov 24, 2014
  17. Jeff KingNov 24, 2014
  18. Junio C HamanoNov 24, 2014
  19. Peter WuNov 24, 2014
  20. Jeff KingNov 25, 2014
  21. Junio C HamanoNov 25, 2014
  22. Jeff KingNov 25, 2014
  23. Peter WuNov 25, 2014
  24. Philip OakleyNov 28, 2014
  25. Peter WuDec 2, 2014
  26. Junio C HamanoDec 2, 2014
  27. Peter WuNov 25, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.