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
Jeff King <peff@peff.net>
Date
Nov 24, 2014, 22:54 UTC
Message-ID
<20141124225457.GA9942@peff.net>
In-Reply-To
<1660121.8PEbpzfRYH@al>
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
Show 8 quoted lines
> > Right. My original complaint was only that "--fetch" is not as
> > orthogonal to "--push" (and an optionless set-url) as it could be. I
> > think the alternatives for going forward are basically:
> > 
> >   1. Name it something besides --fetch (but that's rather clunky).
> 
> It is not orthogonal to --push in the config, but the behavior exposed
> to the user is orthogonal unless I am missing something?

My complaint is that you have three possible options to provide: --push, --fetch, or no option at all. And "--fetch" sometimes behaves like no option, and sometimes not. Which is the confusing/non-orthogonal part.

Show 18 quoted lines
> I can understand that --fetch sounds a bit weird, what about this
> natural translation:
> 
>     "git remote: set the URL (only the fetch one) for NAME to URL"
>     git remote set-url --only=fetch NAME URL
> 
>     "git remote: set the URL (only the push one) for NAME to URL"
>     git remote set-url --only=push NAME URL
>     (obsoletes --push)
> 
>     "git remote: set the URL (both) for NAME to URL"
>     git remote set-url --only=both NAME URL
>     (it would be nice if --only=both (weird!) can be removed in the
>     future such that the option is more natural)
> 
>     "git remote: set the URL for NAME to URL"
>     git remote set-url NAME URL
>     (current behavior: YOU git guru knows what I do right?)

Yeah, I think that addresses my concern (because it explicitly leaves no-option as a historical curiosity, and not as an implicit version of "--both").

Show 8 quoted lines
> >   3. Live with it. Probably address the weirdness in the documentation.
> > 
> >   4. Do nothing, drop the patch.
> > 
> > I think I'd be OK with (3), with an appropriate documentation update.
> 
> I prefer 1 for now as it avoids the extra manual action I have to take
> when changing URLs.

I'm not sure if I was clear on (3), but "live with it" was "live with your original patch". Which I think you would also be happy with.

-Peff
Previous: Peter WuNext: Junio C Hamano
Message 17 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.