Subject: Re: Sources for 3.18-rc1 not uploaded

From: Junio C Hamano <[email-masked]>
Date: Mon, 20 Oct 2014 12:43:37 -0700

Konstantin Ryabitsev <[email-masked]> writes:

> On 20/10/14 02:28 PM, Junio C Hamano wrote:
>> I have to wonder why 10f343ea (archive: honor tar.umask even for pax
>> headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
>> (archive-tar: split long paths more carefully, 2013-01-05), which
>> also should have broken bit-for-bit compatibility, went unnoticed,
>> though.  What I am getting at is that correcting past mistakes in
>> the output should not be forbidden unconditionally with a complaint
>> like this.
>
> I think Greg actually ran into that one, and uses a separate 1.7 git
> tree for this reason.
>
> I can update our servers to git 2.1 (which most of them already have),
> which should help with previous incompatibilities -- but not the future
> ones obviously. :)

Updating to 2.1 will hopefully correct the change in v1.8.1.1~8^2,
and will break Greg and friends who stick to 1.7 for that reason,
though.

The "breakage" in 10f343ea was only in the 'master' branch and
upwards, which is not yet released in any tagged version, and I just
reverted it from my tree, so people on the cutting edge will be okay
in a short order.

Thanks.