git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"Marc Stevens" <marc@marc-stevens.nl>,
	"Michael Kebe" <michael.kebe@gmail.com>,
	"Jeff King" <peff@peff.net>,
	"Brandon Williams" <bmwill@google.com>
Subject: Re: [PATCH v2 0/2] Update sha1dc from upstream & optionally make it a submodule
Date: Tue, 23 May 2017 12:22:00 +0900	[thread overview]
Message-ID: <xmqqtw4cmf53.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kb9Ca6QtyRzOW-1Q-E+7Z+PB7+MBtj4KvZx-mV36opWpA@mail.gmail.com> (Stefan Beller's message of "Mon, 22 May 2017 15:48:45 -0700")

Stefan Beller <sbeller@google.com> writes:

> On Mon, May 22, 2017 at 3:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>>
>>> I liked the suggestion to make the URL a relative path, but this would
>>> require you to maintain a mirror in the same places you push git.git
>>> to, is that something you'd be willing to do?
>>
>> After thinking about this a bit more, I know what I think we want a
>> bit better.
>>
>> Relative URL (e.g. ../sha1collisiondetection that sits next to the
>> copy of git.git) may be a good way to go.  I can arrange to create
>> necessary repository next to git.git on k.org and github.com but I
>> need to double check about other places
>
> And here we see another deficit with a single URL:
> We have to abide by the same scheme at all hosting endpoints.

FWIW, I do not see it a deficit.  It is a price you may or may not
be willing to pay for simplicity, and I think it is a reasonable
trade-off.

The .gitmodules format can be enhanced to list multiple URLs quite
easily.  I think the current users all use the equivalent of "git
config -f .gitmodules submodule.foo.url" to grab one value.  Unless
the user chooses to do anything special, they will continue to get
the same behaviour whensuch an enhancement happens, which is a good
thing.

But then, you need to design what users choose to do that is
"something special".  Should "git clone --recurse-submodules" have a
way to control which one of the not-yet-known-before-cloning URLs
that may be listed in .gitmodules?  Will we have a way to say "For
North American users, we recommend this URL, while Asians may want
to fetch from this other URL" in .gitmodules and then the recursive
clone have a way to say "I want the European option"?  Would the
recursive clone have a way to go interactive?

And from that point of view, "you'll find the submodules relative to
the superproject" convention is one way (not necessarily the only
way) to allow users not to care too much.  The simplicity comes with
price and that is perfectly acceptable.

Also a single URL scheme may still perfectly fine.  .gitmodules may
have new submodule.<name>.alternateURL fields and recursive clone
can be told to optionally go interactive when such fields are
present.

Or README can list alternate URLs and instruct the users to use the
insteadOf if they want to go to mirrors instead.  Those users who do
care about picking particular mirror are likely not favor simplicity
over flexibility, so they would not likely to do a recursive clone
(after all, clone is a single-time operation) and it may be
sufficient if they can clone the top-level, read README and then
decide how and from where they get their submodules.

  reply	other threads:[~2017-05-23  3:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 21:28 [PATCH 0/3] Update sha1dc from upstream & optionally make it a submodule Ævar Arnfjörð Bjarmason
2017-05-18 21:28 ` [PATCH 1/3] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2017-05-18 21:28 ` [PATCH 2/3] sha1dc: use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-05-20 11:13   ` Junio C Hamano
2017-05-20 11:54     ` [PATCH v2 0/2] Update sha1dc from upstream & optionally make it " Ævar Arnfjörð Bjarmason
2017-05-22 22:27       ` Junio C Hamano
2017-05-22 22:48         ` Stefan Beller
2017-05-23  3:22           ` Junio C Hamano [this message]
2017-05-23 10:55         ` Ævar Arnfjörð Bjarmason
2017-05-23 13:06           ` Junio C Hamano
2017-05-25 10:44             ` Ævar Arnfjörð Bjarmason
2017-05-25 23:31               ` Junio C Hamano
2017-05-20 11:54     ` [PATCH v2 1/2] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2017-05-20 11:54     ` [PATCH v2 2/2] sha1dc: optionally use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason
2017-05-22  1:33       ` Junio C Hamano
2017-05-22  2:48         ` Junio C Hamano
2017-05-22  8:27           ` Ævar Arnfjörð Bjarmason
2017-05-22  8:48             ` Junio C Hamano
2017-05-25 10:47     ` [PATCH 2/3] sha1dc: " Ævar Arnfjörð Bjarmason
2017-05-18 21:28 ` [PATCH 3/3] sha1dc: remove the unused sha1dc/ directory Ævar Arnfjörð Bjarmason

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=xmqqtw4cmf53.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=marc@marc-stevens.nl \
    --cc=michael.kebe@gmail.com \
    --cc=peff@peff.net \
    --cc=sbeller@google.com \
    /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).