Re: Sources for 3.18-rc1 not uploaded

[Greg KH <greg@kroah.com>]

On Mon, Oct 20, 2014 at 02:37:09PM -0400, Konstantin Ryabitsev wrote:
> 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 used to have to do this for the 3.0-stable kernel as one of the files
in it ran into the "very long path" problem.  I just ran the latest
version of git with that one commit reverted and all was fine.

After 3.0 was done, I just dropped that patch from my local version and
have been running with the latest git version of git with no problems.

> 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. :)

I thought you already did this.  Or was that only the public facing git
servers?

thanks,

greg k-h