Re: [PATCH 3/4] Makefile: use the sha1collisiondetection submodule by default
- Date: Tue, 05 Dec 2017 15:16:41 +0100
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: [PATCH 3/4] Makefile: use the sha1collisiondetection submodule by default
On Tue, Dec 05 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>>> I'm not sure how I feel about this. I see your point that there's no
>>> real value in maintaining two systems indefinitely. At the same time, I
>>> wonder how much value the submodule strategy is actually bringing us.
>>> IOW, are we agreed that the path forward is to get everybody using the
>> In no particular order:
>> * I don't feel strongly about 2-4/4 in this series. I just hacked this
>> up because it occurred to me that I'd left this sha1dc stuff in some
>> in-between state and we'd talked about eventually moving forward with
>> We've had two releases with the submodule being purely optional, if
>> we're going to keep it it seems logical to start at least using it by
> With a need for a patch like 1/4, I suspect two release cycles is
> way too short for making a move like 2-4/4, though.
You're conflating two unrelated things, which to be fair I'm confusingly
doing by submitting all this together.
1) Since 2.14 we've had the "auto" rule and
DC_SHA1_SUBMODULE=[YesPlease|auto], so we'll prefer the submodule if
it's there. So we've been testing if the mere presence of a
.gitmodules breaks something for someone, seems like it doesn't.
2) Then in the 2.15 release Takashi Iwai submitted a feature to link to
an external SHA1DC. This is used in the SuSE 2.15 package here:
However, as you'll see if you extract that package they don't run
into that bug, because they're building it from a tarball which has
an empty sha1collisiondetection/ directory as noted in my
Takashi *would* run into an error with my 1/4 if he was building from
git.git, or if "make dist" included sha1collisiondetection/, but I
don't see a reason to hold anything back back on that account. The
only users of DC_SHA1_EXTERNAL=YesPlease are going to be packagers
who know what they're doing, and if we start erroring out for them on
this obscure option that's going to be trivially solved.
I don't see why this obscure edge case with #2 should keep us from
deciding whatever we'd decide with #1. They're really unrelated, #2
practically speaking only impacts tarball consumers, #1 impacts git.git
It seems logical to me if we're going to move forward with #1 at all by
first making the submodule the default & then depending on how that
turns out making it a hard dependency, we'd do it now.
We'll learn nothing new by shipping a 2.16 with DC_SHA1_SUBMODULE=auto
that we haven't already learned in 2.14 & 2.15.