git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Junio C Hamano <gitster@pobox.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: Mon, 11 Mar 2019 14:23:29 -0400
Message-ID: <20190311182328.GB16865@sigill.intra.peff.net> (raw)
In-Reply-To: <8cf2fa6c-d742-a2a6-cde7-66cef87b04e8@virtuell-zuhause.de>

On Mon, Mar 11, 2019 at 07:15:12PM +0100, Thomas Braun wrote:

> Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
> > On Mon, Mar 11, 2019 at 10:48 AM Jeff King <peff@peff.net> wrote:
> >> And AFAIK there is no good way to
> >> modify the submodule-provided content as part of the build. Why do we
> >> even have the submodule again? ;P
> > 
> > Because of dogfooding of course. This is an interesting use case
> > though. I wonder if people often want to "patch" submodules like this
> > (and what we could do if that's the case)
> 
> I usually do the following:
> 
> - Fork the sub-project
> - Add a branch with my proposed patches
> - Update the URL and the commit of the submodule in the super-project
> 
> This of course requires all users to do
> 
> git submodule sync
> 
> which is a bit incovenient, but works.

The problem to me is not that the steps that a developer has to do, but
rather that we are dependent on the upstream project to make a simple
fix (which they may not agree to do, or may take a long time to do).

Whereas if we import the content into our repo as a subtree, we are free
to hack it up as we see fit, and then occasionally pull from upstream
and reconcile the changes. Changing upstream isn't advisable in the
general case, but I think makes a lot of sense for small changes
(especially if you have the discipline to actually get the same or
similar change pushed upstream).

In this particular case, though, the sha1dc project is pretty
responsive, so I don't think it's going to be a big deal. It just seems
like an anti-pattern in general.

-Peff

  reply	other threads:[~2019-03-11 18:23 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 [this message]
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
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=20190311182328.GB16865@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=noloader@gmail.com \
    --cc=pclouds@gmail.com \
    --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