git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Calvin Wan <calvinwan@google.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] Documentation: clarify multiple pushurls vs urls
Date: Mon, 06 Feb 2023 15:00:50 -0800	[thread overview]
Message-ID: <xmqqfsbi2ycd.fsf@gitster.g> (raw)
In-Reply-To: <CAFySSZCO7M8bm8Cc97x7MpZYHd0qWwRHF_YRDmw1rryF6Q7dnQ@mail.gmail.com> (Calvin Wan's message of "Mon, 6 Feb 2023 13:12:06 -0800")

Calvin Wan <calvinwan@google.com> writes:

> If a user wants one url to push/fetch to, then he defines 'url'
> If a user wants to push to multiple urls, then he can either define

meaning "the user wants to push to multiple, but never wants to
fetch from the other ones"?  If so, then ...

> multiple urls or pushurls (one of the pushurls can be the same as the url).

... using multiple urls is not desirable as it becomes hard to tell
which one should be used for fetching.  

When you define additional places you want to publish to, you do not
expect to see that new definition affect where you fetch from.  In a
sense, using the first one to fetch, not the last one, gives us less
damage, for that reason.  Adding more URLs would not change where
you fetch from.

But still, I think what you gave is a good rule, regardless of the
answer to the "which among multiple non-push urls do we fetch"
question.  If we were designing this part of the system from
scratch, we probably 

 - would have forbidden multiple URLs, or
 - would allowed multiple URLs, but used the 'last one wins', or
 - would allowed multiple URLs, but and used later ones as fallback,
   only to be used when earlier ones fail.

It certainly is not a designed behaviour what we do when we have
multiple URLs, but if we haven't changed how we react to such a
configuration in the past (and I do not think we ever did), changing
the behaviour in any way this late in the game likely breaks real
users' configuration.

Thanks.

      parent reply	other threads:[~2023-02-06 23:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06 19:55 [PATCH] Documentation: clarify multiple pushurls vs urls Calvin Wan
2023-02-06 20:11 ` Ævar Arnfjörð Bjarmason
2023-02-06 21:12   ` Calvin Wan
2023-02-06 21:55     ` Ævar Arnfjörð Bjarmason
2023-02-06 23:00     ` Junio C Hamano [this message]

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=xmqqfsbi2ycd.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=calvinwan@google.com \
    --cc=git@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).