git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Thomas Braun <thomas.braun@virtuell-zuhause.de>,
	Junio C Hamano <gitster@pobox.com>,
	Duy Nguyen <pclouds@gmail.com>,
	Jeffrey Walton <noloader@gmail.com>,
	Todd Zullinger <tmz@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29
Date: Wed, 13 Mar 2019 17:00:20 +0100
Message-ID: <87lg1ibw8b.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20190313153923.GC24101@sigill.intra.peff.net>


On Wed, Mar 13 2019, Jeff King wrote:

> On Wed, Mar 13, 2019 at 12:47:51PM +0100, Thomas Braun wrote:
>
>> > Reading Thomas's email again, that might actually have been what he was
>> > recommending. If so, sorry for the confusion. And I agree that's a valid
>> > solution.
>>
>> Yes that is what I tried to explain. Looks like it was lost in translation.
>
> I think the problem was on the reading end. :)
>
>> > That said, I do wonder at some point if there's a huge value in using a
>> > submodule at that point. I think there is if the dependent project is
>> > large (and if it's optional, and some people might not need it). But in
>> > this case, it is not a big deal to just carry the sha1dc code in-tree.
>>
>> A big win with submodules is that you have separate histories and can,
>> quite easily, update to newer versions without manual copying.
>
> True. We'd generally be picking up snapshots in our in-tree sha1dc/, so
> bisecting on it is not as fine-grained. We _could_ pull in the full
> history using something like git-subtree, but that comes with its own
> complications.
>
>> One grievance with submodules is the URL switching if you need to go
>> with a forked repo for some time and then back to the original.
>> Is it possible to have multiple remotes for a submodule?
>>
>> Something like:
>>
>> [submodule "libfoo"]
>> 	path = include/foo
>> 	url1 = git://foo.com/upstream/lib.git
>> 	url2 = git://foo.com/myFork/lib.git
>>
>> With that the error prone git submodule sync step is not required anymore.
>
> I assume you'd fetch from _all_ of them during a fetch, and assume that
> one of them will get you the objects you need (or I guess if you are
> looking for a specific object, you'd try them one at a time until you
> get the object).
>
> That makes sense, though it might be kind of annoying when fetching is
> expensive (especially if it involves manually authenticating).
>
>> submodule.alternateLocation looks like it is going into the right direction.
>
> I think that's mostly about pointing back to the superproject for local
> storage. Though I think there's a pretty reasonable solution to the
> problem we're discussing there: git.git could carry a "sha1dc" branch
> that points to our modified submodule history. So it's "in-tree" in the
> sense that that it is in our repo, and under our full control, but still
> managed like a submodule.
>
> And we'd probably not even duplicate a lot of storage in the actual
> clone of the upstream project, because it would be pointing to us as an
> alternate.

Now if only we could think of some way to give the people best
positioned to fix some of these UI issues for git users everywhere the
incentive to do so[1] :)

1. https://public-inbox.org/git/20171208223001.556-5-avarab@gmail.com/

  reply	other threads:[~2019-03-13 16:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 10:48 Jeffrey Walton
2019-03-08 17:43 ` Todd Zullinger
2019-03-09 12:34   ` Jeffrey Walton
2019-03-09 13:12     ` Jeffrey Walton
2019-03-11  2:00       ` Junio C Hamano
2019-03-11  2:16         ` Jeffrey Walton
2019-03-11  3:37         ` disabling sha1dc unaligned access, was " Jeff King
2019-03-11 10:40           ` Jeffrey Walton
2019-03-11 18:19             ` Jeff King
2019-03-11 11:58           ` Duy Nguyen
2019-03-11 18:15             ` Thomas Braun
2019-03-11 18:23               ` Jeff King
2019-03-12  7:27                 ` Junio C Hamano
2019-03-12 10:51                   ` Jeff King
2019-03-13 11:47                     ` Thomas Braun
2019-03-13 15:39                       ` Jeff King
2019-03-13 16:00                         ` Ævar Arnfjörð Bjarmason [this message]
2019-03-12  8:53                 ` Ævar Arnfjörð Bjarmason
2019-03-12 11:05                   ` Jeff King
2019-03-12 12:09                     ` Ævar Arnfjörð Bjarmason
2019-03-12 21:01                       ` Jeff King
2019-03-12 21:06           ` [PATCH] Makefile: fix unaligned loads in sha1dc with UBSan Jeff King
2019-03-12 21:17             ` Ævar Arnfjörð Bjarmason
2019-03-12 21:19               ` Jeff King
2019-03-11  3:29     ` One failed self test on Fedora 29 Jeff King

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=87lg1ibw8b.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=noloader@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=thomas.braun@virtuell-zuhause.de \
    --cc=tmz@pobox.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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git