Konstantin Ryabitsev <konstan...@linuxfoundation.org> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
