git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Marc Stevens <marc@marc-stevens.nl>,
	Michael Kebe <michael.kebe@gmail.com>, Jeff King <peff@peff.net>,
	Stefan Beller <sbeller@google.com>,
	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 07:27:41 +0900	[thread overview]
Message-ID: <xmqqbmqko7c2.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170520115429.12289-1-avarab@gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Sat, 20 May 2017 11:54:27 +0000")

Æ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

Whether the submodule is referenced by a relative URL from the main
project, the submodule should not come directly from the upstream,
and various mirrors that sit next to git.git should not be blind and
automated "mirrors".  This is because I do not want us to trust the
security measures of https://github.com/cr-marcstevens/ repository.
The consumers already need to trust k.org/pub/scm/git/git.git and by
ensuring k.org/pub/scm/git/sha1dc is managed the same way, they do
not have to trust anything extra.

Another reason is that we want to make sure all commits in the
submodule that we bind to the superproject (i.e. git.git) are always
in the submodule, regardless of what our upstream does, and one way
to do so is to have control over _our_ canonical repository for the
submodule.  In normal times, it will faithfully follow the upstream
without doing anything else, but we'd keep the option of anchoring a
submodule commit that is referenced by the superproject history with
our own tag, if it is ever rewound away in the upstream history for
whatever reason.

Thanks.

  reply	other threads:[~2017-05-22 22:27 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 [this message]
2017-05-22 22:48         ` Stefan Beller
2017-05-23  3:22           ` Junio C Hamano
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=xmqqbmqko7c2.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).