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

Re: [BUG] Possible bug in `remote set-url --add --push`

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jan 16, 2013, 16:24 UTC
Message-ID
<50F6D43D.2000509@drmicha.warpmail.net>
In-Reply-To
<CABURp0rR_wB6vcjrZajQU_=AVVvBq-aTGpggh5XxdCMYis3-ag@mail.gmail.com>
Phil Hord venit, vidit, dixit 16.01.2013 17:15:
Show 10 quoted lines
> On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> That being said, I don't mind changing the behaviour of set-url.
>>
>> I do not think we want to change the behaviour of set-url.
> 
> I agree with Michael that changing the set-url behavior would be
> appropriate here.  If I say "--add" this pushUrl, don't I mean to
> create an additional url which is pushed to?
I said I wouldn't mind, I didn't vote for it.
Show 18 quoted lines
> I agree that it makes the config situation messy; this is currently a
> "clean" sequence, in that it leaves the config unchanged after both
> steps are completed:
> 
>   git remote set-url --add --push origin /tmp/foo
>   git remote set-url --delete --push origin /tmp/foo
> 
> If the behavior is changed like Michael suggested, it would not leave
> the config clean (unless heroic steps were taken to keep track).  But
> I'm not sure that's such a bad thing.  In simple command sequences,
> the results would be clean and the only behavior change is that the
> initial "--add" really acts like "add" and not "replace".  But more
> complex sequences could be devised which were affected by this change.
> 
> I'm curious, Junio.  Do you think the set-url behavior is correct
> as-is, or that changing it will cause breakage for some workflows, or
> that it complicates the operation too much for people who are already
> used to the config layout?

For "set url --add --push" on top of a push url only being defaulted from a fetch url, both behaviours (replace or add, i.e. current or new) make sense to me. So the questions are:

- Is it worth and possible changing?
- How to best describe it in "remote -v" and "remote show" output?

My patch answered to "no" to the first question and answers the second one in cases where (push)insteadof is not used to transform one fetch config into two different urls for fetch and push. I think :)

Michael
Previous: Phil Hord
Message 27 of 27 in “[BUG] Possible bug in `remote set-url --add --push`”
  1. Jardel WeyrichJan 12, 2013
  2. Junio C HamanoJan 12, 2013
  3. Jardel WeyrichJan 12, 2013
  4. Junio C HamanoJan 12, 2013
  5. Sascha CunzJan 12, 2013
  6. Jardel WeyrichJan 12, 2013
  7. Michael J GruberJan 14, 2013
  8. Jonathan NiederJan 14, 2013
  9. Junio C HamanoJan 14, 2013
  10. Jardel WeyrichJan 15, 2013
  11. Junio C HamanoJan 15, 2013
  12. Junio C HamanoJan 15, 2013
  13. Michael J GruberJan 15, 2013
  14. Junio C HamanoJan 15, 2013
  15. Michael J GruberJan 16, 2013
  16. Junio C HamanoJan 16, 2013
  17. Michael J GruberJan 16, 2013
  18. Andreas SchwabJan 16, 2013
  19. Junio C HamanoJan 16, 2013
  20. git-remote: distinguish between default and configured URLsMichael J Gruber, Jan 16, 2013
  21. Michael J GruberJan 16, 2013
  22. John KeepingJan 16, 2013
  23. Michael J GruberJan 16, 2013
  24. John KeepingJan 16, 2013
  25. Junio C HamanoJan 16, 2013
  26. Phil HordJan 16, 2013
  27. Michael J GruberJan 16, 2013

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.