{"thread":{"id":"32795","subject":"\"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","startedAt":"2013-01-31T17:28:05Z","lastAt":"2013-02-04T18:26:34Z","messageCount":11,"participants":["Greg KH","Junio C Hamano","Konstantin Ryabitsev","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"208369","messageId":"20130131172805.GC16593@kroah.com","threadId":"32795","inReplyTo":null,"subject":"\"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2013-01-31T17:28:05Z","receivedAt":"2013-01-31T17:28:05Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"Hi,\n\nThe way we upload the Linux kernel to kernel.org involves creating a tar\narchive, signing the archive, and then just uploading the signature.\nThe server then checks out the repo based on the tag, generates the tar\narchive and checks the signature to make sure they match.\n\nA few days ago I released the 3.0.61 kernel, and it turned out that I\ncouldn't upload the kernel release because 'git archive' now creates a\nbinary file that differs from an older version of git.\n\nI tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546\n(archive-tar: split long paths more carefully).  The diff of a hex dump\nof the tar archives shows the following difference:\n\n--- old_git_archive\t2013-01-31 17:31:24.466343388 +0100\n+++ new_git_archive\t2013-01-31 17:32:21.509674417 +0100\n@@ -19239998,8 +19239998,8 @@\n 125943d0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 125943e0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 125943f0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n-12594400:0000 0000 0000 0000 0000 0000 0000 0000  ................\n-12594410:0000 0000 0000 0000 0000 0000 0000 0000  ................\n+12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033  westbridge-omap3\n+12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000  -pnand-hal/.....\n 12594420:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 12594430:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 12594440:0000 0000 0000 0000 0000 0000 0000 0000  ................\n@@ -19240025,8 +19240025,8 @@\n 12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172  /astoria/arch/ar\n 12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c  m/plat-omap/incl\n 125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269  ude/mach/westbri\n-125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f  dge/westbridge-o\n-125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000  map3-pnand-hal..\n+125945b0:6467 6500 0000 0000 0000 0000 0000 0000  dge.............\n+125945c0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 125945d0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 125945e0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n 125945f0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n\nInterestingly, the output of uncompressing the tar archives is\nidentical, so the data is correct, but the binary isn't.\n\nNow keeping binary compatibility of tar archive files isn't really a big\ndeal, but, the commit to git that causes this seems a bit odd, is it\nreally needed?  Or can we just fix the version of tar with NetBSD\ninstead?  :)\n\nAny ideas?\n\nthanks,\n\ngreg k-h\n"},{"id":"208370","messageId":"7vzjzpgswz.fsf@alter.siamese.dyndns.org","threadId":"32795","inReplyTo":"20130131172805.GC16593@kroah.com","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T17:32:12Z","receivedAt":"2013-01-31T17:32:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH <gregkh@linuxfoundation.org> writes:\n\n> The way we upload the Linux kernel to kernel.org involves creating a tar\n> archive, signing the archive, and then just uploading the signature.\n> The server then checks out the repo based on the tag, generates the tar\n> archive and checks the signature to make sure they match.\n> \n> A few days ago I released the 3.0.61 kernel, and it turned out that I\n> couldn't upload the kernel release because 'git archive' now creates a\n> binary file that differs from an older version of git.\n> ...\n> Now keeping binary compatibility of tar archive files isn't really a big\n> deal, but, the commit to git that causes this seems a bit odd, is it\n> really needed?  Or can we just fix the version of tar with NetBSD\n> instead?  :)\n>\n> Any ideas?\n\nHow about fixing kup to teach the \"let's cheat and let the other end\nrun 'git archive', if the resulting archive and GPG signature\nlocally created does match, we do not have to transfer the tarball\nitself\" trick a fall-back mode that says \"but if the signature does\nnot match, then transfer the bulk used to create the signature to\nthe remote anyway\".  This fallback can and should of course be\nuseful for the compressed patch transfer.\n"},{"id":"208372","messageId":"20130131174103.GA20111@kroah.com","threadId":"32795","inReplyTo":"7vzjzpgswz.fsf@alter.siamese.dyndns.org","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2013-01-31T17:41:03Z","receivedAt":"2013-01-31T17:41:03Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:\n> Greg KH <gregkh@linuxfoundation.org> writes:\n> \n> > The way we upload the Linux kernel to kernel.org involves creating a tar\n> > archive, signing the archive, and then just uploading the signature.\n> > The server then checks out the repo based on the tag, generates the tar\n> > archive and checks the signature to make sure they match.\n> > \n> > A few days ago I released the 3.0.61 kernel, and it turned out that I\n> > couldn't upload the kernel release because 'git archive' now creates a\n> > binary file that differs from an older version of git.\n> > ...\n> > Now keeping binary compatibility of tar archive files isn't really a big\n> > deal, but, the commit to git that causes this seems a bit odd, is it\n> > really needed?  Or can we just fix the version of tar with NetBSD\n> > instead?  :)\n> >\n> > Any ideas?\n> \n> How about fixing kup to teach the \"let's cheat and let the other end\n> run 'git archive', if the resulting archive and GPG signature\n> locally created does match, we do not have to transfer the tarball\n> itself\" trick a fall-back mode that says \"but if the signature does\n> not match, then transfer the bulk used to create the signature to\n> the remote anyway\".  This fallback can and should of course be\n> useful for the compressed patch transfer.\n\nUgh, uploading a 431Mb file, over a flaky wireless connection (I end up\ndoing lots of kernel releases while traveling), would be a horrible\nchange.  I'd rather just keep using the same older version of git that\nkernel.org is running instead.\n\nthanks,\n\ngreg k-h\n"},{"id":"208373","messageId":"510AAF4F.6060201@kernel.org","threadId":"32795","inReplyTo":"20130131174103.GA20111@kroah.com","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Konstantin Ryabitsev","fromEmail":"mricon@kernel.org","sentAt":"2013-01-31T17:52:15Z","receivedAt":"2013-01-31T17:52:15Z","isPatch":false,"sender":{"key":"mricon@kernel.org","avatar":"https://gravatar.com/avatar/d74ca8eb882d19f551bebba2b75663fd9032ab8590103b23ec87236dcd7f349b?d=mp&s=160"},"body":"On 31/01/13 12:41 PM, Greg KH wrote:\n> Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up\n> doing lots of kernel releases while traveling), would be a horrible\n> change.  I'd rather just keep using the same older version of git that\n> kernel.org is running instead.\n\nWell, we do accept compressed archives, so you would be uploading about\n80MB instead of 431MB, but that would still be a problem for anyone\nreleasing large tarballs over unreliable connections. I know you\nroutinely do 2-3 releases at once, so that would still mean uploading\n120-180MB.\n\nI don't have immediate statistics on how many people release using \"kup\n--tar\", but I know that at least you and Linus rely on that exclusively.\n\n\nRegards,\n-- \nKonstantin Ryabitsev\nSystems Administrator\nLinux Foundation, kernel.org\nMontréal, Québec\n\n"},{"id":"208377","messageId":"7vr4l1gqv8.fsf@alter.siamese.dyndns.org","threadId":"32795","inReplyTo":"20130131174103.GA20111@kroah.com","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T18:16:27Z","receivedAt":"2013-01-31T18:16:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH <gregkh@linuxfoundation.org> writes:\n\n> On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:\n>\n>> How about fixing kup to teach the \"let's cheat and let the other end\n>> run 'git archive', if the resulting archive and GPG signature\n>> locally created does match, we do not have to transfer the tarball\n>> itself\" trick a fall-back mode that says \"but if the signature does\n>> not match, then transfer the bulk used to create the signature to\n>> the remote anyway\".  This fallback can and should of course be\n>> useful for the compressed patch transfer.\n>\n> Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up\n> doing lots of kernel releases while traveling), would be a horrible\n> change.  I'd rather just keep using the same older version of git that\n> kernel.org is running instead.\n\nThen how about fixing kup to try both versions of Git?  There will\nbe people who run different versions of Git anyway, and kup should\nnot be preventing Git from helping people on other platforms, or\nimproving its output in general.\n"},{"id":"208380","messageId":"510AB910.5050504@lsrfire.ath.cx","threadId":"32795","inReplyTo":"20130131172805.GC16593@kroah.com","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2013-01-31T18:33:52Z","receivedAt":"2013-01-31T18:33:52Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 31.01.2013 18:28, schrieb Greg KH:\n> I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546\n> (archive-tar: split long paths more carefully).  The diff of a hex dump\n> of the tar archives shows the following difference:\n> \n> --- old_git_archive\t2013-01-31 17:31:24.466343388 +0100\n> +++ new_git_archive\t2013-01-31 17:32:21.509674417 +0100\n> @@ -19239998,8 +19239998,8 @@\n>  125943d0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  125943e0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  125943f0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> -12594400:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> -12594410:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033  westbridge-omap3\n> +12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000  -pnand-hal/.....\n>  12594420:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  12594430:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  12594440:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> @@ -19240025,8 +19240025,8 @@\n>  12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172  /astoria/arch/ar\n>  12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c  m/plat-omap/incl\n>  125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269  ude/mach/westbri\n> -125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f  dge/westbridge-o\n> -125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000  map3-pnand-hal..\n> +125945b0:6467 6500 0000 0000 0000 0000 0000 0000  dge.............\n> +125945c0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  125945d0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  125945e0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n>  125945f0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n\nThis is the only directory in the repository whose path is long enough to\nmake a difference with the patch, 105 characters in total:\n\ndrivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/\n\nFive characters less and you wouldn't notice a thing.  It contains\n\"westbridge\" thrice, so I think it's cheating just to reach that\nlength, though. ;-)\n\n> Interestingly, the output of uncompressing the tar archives is\n> identical, so the data is correct, but the binary isn't.\n\nThe path is split differently between two header fields, that's all.\n\n> Now keeping binary compatibility of tar archive files isn't really a big\n> deal, but, the commit to git that causes this seems a bit odd, is it\n> really needed?  Or can we just fix the version of tar with NetBSD\n> instead?  :)\n\nApart from Junio's suggestion, I can't think of a practical solution.\n\nYou could downgrade your git to a version before the fix.  A downside is\nthat you won't be able to extract the archive on NetBSD without getting\nan error message (but the contents would be intact, except perhaps for\npermission bits of the directory above).\n\nYou could upgrade the kernel.org version of git, but that might cause the\nsame problem for other maintainers with long directory paths who in their\nrepositories who still use git without the fix.\n\nYou could make the path shorter.  Won't help at all with the release you\njust did, of course.\n\nI don't know if other tar implementations freak out when they see an\nempty name field.  NetBSD's tar might seem a bit too strict here, but\noverall I think it's right in complaining.\n\nWhat makes the commit odd, by the way?\n\nThanks,\nRené\n"},{"id":"208585","messageId":"20130204004251.GA6243@kroah.com","threadId":"32795","inReplyTo":"510AB910.5050504@lsrfire.ath.cx","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2013-02-04T00:42:51Z","receivedAt":"2013-02-04T00:42:51Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Thu, Jan 31, 2013 at 07:33:52PM +0100, René Scharfe wrote:\n> Am 31.01.2013 18:28, schrieb Greg KH:\n> > I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546\n> > (archive-tar: split long paths more carefully).  The diff of a hex dump\n> > of the tar archives shows the following difference:\n> > \n> > --- old_git_archive\t2013-01-31 17:31:24.466343388 +0100\n> > +++ new_git_archive\t2013-01-31 17:32:21.509674417 +0100\n> > @@ -19239998,8 +19239998,8 @@\n> >  125943d0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  125943e0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  125943f0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> > -12594400:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> > -12594410:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> > +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033  westbridge-omap3\n> > +12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000  -pnand-hal/.....\n> >  12594420:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  12594430:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  12594440:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> > @@ -19240025,8 +19240025,8 @@\n> >  12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172  /astoria/arch/ar\n> >  12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c  m/plat-omap/incl\n> >  125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269  ude/mach/westbri\n> > -125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f  dge/westbridge-o\n> > -125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000  map3-pnand-hal..\n> > +125945b0:6467 6500 0000 0000 0000 0000 0000 0000  dge.............\n> > +125945c0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  125945d0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  125945e0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> >  125945f0:0000 0000 0000 0000 0000 0000 0000 0000  ................\n> \n> This is the only directory in the repository whose path is long enough to\n> make a difference with the patch, 105 characters in total:\n> \n> drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/\n> \n> Five characters less and you wouldn't notice a thing.  It contains\n> \"westbridge\" thrice, so I think it's cheating just to reach that\n> length, though. ;-)\n\nYeah, that file path was bad, which is just one reason why it was\ndeleted from the kernel in newer versions :)\n\n> > Interestingly, the output of uncompressing the tar archives is\n> > identical, so the data is correct, but the binary isn't.\n> \n> The path is split differently between two header fields, that's all.\n\nOk, thanks for the explaination, I didn't realize that.\n\n> > Now keeping binary compatibility of tar archive files isn't really a big\n> > deal, but, the commit to git that causes this seems a bit odd, is it\n> > really needed?  Or can we just fix the version of tar with NetBSD\n> > instead?  :)\n> \n> Apart from Junio's suggestion, I can't think of a practical solution.\n> \n> You could downgrade your git to a version before the fix.  A downside is\n> that you won't be able to extract the archive on NetBSD without getting\n> an error message (but the contents would be intact, except perhaps for\n> permission bits of the directory above).\n> \n> You could upgrade the kernel.org version of git, but that might cause the\n> same problem for other maintainers with long directory paths who in their\n> repositories who still use git without the fix.\n> \n> You could make the path shorter.  Won't help at all with the release you\n> just did, of course.\n\nWhat I ended up doing was just to revert your patch, generating a tar\narchive that matches what the version on kernel.org.\n\nAnd originally I now recall that this was something we were worried\nabout, but we put off dealing with it until it caused problems :)\n\n> I don't know if other tar implementations freak out when they see an\n> empty name field.  NetBSD's tar might seem a bit too strict here, but\n> overall I think it's right in complaining.\n\nOk, thanks, I now agree.\n\n> What makes the commit odd, by the way?\n\nSorry, I was originally thinking that you were working around a bug in\nthe NetBSD version of tar, not making it \"more correct\", which is\narguably the right thing to do here.\n\nSo I'll work with Konstantine to ensure we both are using the same\nversion of git in the future, it's our kernel.org infrastructure issue\nhere, not a git one, sorry for the noise.\n\ngreg k-h\n"},{"id":"208583","messageId":"20130204004512.GB6243@kroah.com","threadId":"32795","inReplyTo":"7vr4l1gqv8.fsf@alter.siamese.dyndns.org","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2013-02-04T00:45:12Z","receivedAt":"2013-02-04T00:45:12Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Thu, Jan 31, 2013 at 10:16:27AM -0800, Junio C Hamano wrote:\n> Greg KH <gregkh@linuxfoundation.org> writes:\n> \n> > On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:\n> >\n> >> How about fixing kup to teach the \"let's cheat and let the other end\n> >> run 'git archive', if the resulting archive and GPG signature\n> >> locally created does match, we do not have to transfer the tarball\n> >> itself\" trick a fall-back mode that says \"but if the signature does\n> >> not match, then transfer the bulk used to create the signature to\n> >> the remote anyway\".  This fallback can and should of course be\n> >> useful for the compressed patch transfer.\n> >\n> > Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up\n> > doing lots of kernel releases while traveling), would be a horrible\n> > change.  I'd rather just keep using the same older version of git that\n> > kernel.org is running instead.\n> \n> Then how about fixing kup to try both versions of Git?  There will\n> be people who run different versions of Git anyway, and kup should\n> not be preventing Git from helping people on other platforms, or\n> improving its output in general.\n\nI think the combinations of different versions of git that would have to\nbe installed on kernel.org to handle stuff like this as things change\nover time, wouldn't be worth it.\n\nThe number of people this affects right now is only one (me), given that\nthe offending file is not in Linus's tree right now, so he doesn't have\nissues with uploading new releases.\n\nSo I'll just work to ensure I have the same version of git in place if I\never run into this problem again.  Or just break down and do\nfull-compressed tarballs instead, if I'm in a place where I have a good\nnetwork connection.\n\nthanks,\n\ngreg k-h\n"},{"id":"208584","messageId":"20130204004800.GC6243@kroah.com","threadId":"32795","inReplyTo":"510AAF4F.6060201@kernel.org","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2013-02-04T00:48:00Z","receivedAt":"2013-02-04T00:48:00Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Thu, Jan 31, 2013 at 12:52:15PM -0500, Konstantin Ryabitsev wrote:\n> On 31/01/13 12:41 PM, Greg KH wrote:\n> > Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up\n> > doing lots of kernel releases while traveling), would be a horrible\n> > change.  I'd rather just keep using the same older version of git that\n> > kernel.org is running instead.\n> \n> Well, we do accept compressed archives, so you would be uploading about\n> 80MB instead of 431MB, but that would still be a problem for anyone\n> releasing large tarballs over unreliable connections. I know you\n> routinely do 2-3 releases at once, so that would still mean uploading\n> 120-180MB.\n\nThat would mean I can't do kernel releases while on ferry rides, which\nis probably a good thing in the end :)\n\n> I don't have immediate statistics on how many people release using \"kup\n> --tar\", but I know that at least you and Linus rely on that exclusively.\n\nWhat causes you to upgrade the version of git on the server?  Are you\nrelying on packages for a distro, or is this \"hand installed\" by\nyourself?  As long as I stay in lock-step with your updates, all should\nbe fine.\n\nOh, maybe we can report back to the user, the version of git that is\nbeing used on the server, if the checksums don't match, so that I know\nto at least see if my version is different from yours?\n\nthanks,\n\ngreg k-h\n"},{"id":"208587","messageId":"7vvca8653g.fsf@alter.siamese.dyndns.org","threadId":"32795","inReplyTo":"20130204004512.GB6243@kroah.com","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T05:05:55Z","receivedAt":"2013-02-04T05:05:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH <gregkh@linuxfoundation.org> writes:\n\n>> Then how about fixing kup to try both versions of Git?  There will\n>> be people who run different versions of Git anyway, and kup should\n>> not be preventing Git from helping people on other platforms, or\n>> improving its output in general.\n>\n> I think the combinations of different versions of git that would have to\n> be installed on kernel.org to handle stuff like this as things change\n> over time, wouldn't be worth it.\n\nYou make it sound as if you have to pick the right one among 47\ndifferent versions, but I think over the lifetime of Git there was\nonly one time that output from \"diff\" would have affected the kup's\ntrick to avoid the transmission of patch text, and another that\noutput from \"tar-tree\" (aka \"archive --format=tar\") would have\nafffected the transmission of tarballs.  I do think it is feasible\nif \"kup\" wanted to.\n\n> The number of people this affects right now is only one (me), given that\n> the offending file is not in Linus's tree right now, so he doesn't have\n> issues with uploading new releases.\n\nAs a tree grows larger over time, it may be just a matter of time\nfor somebody else to be hit by another deep path, though.\n"},{"id":"208632","messageId":"20130204182634.GC3219@kroah.com","threadId":"32795","inReplyTo":"7vvca8653g.fsf@alter.siamese.dyndns.org","subject":"Re: \"git archve --format=tar\" output changed from 1.8.1 to 1.8.2.1","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2013-02-04T18:26:34Z","receivedAt":"2013-02-04T18:26:34Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Sun, Feb 03, 2013 at 09:05:55PM -0800, Junio C Hamano wrote:\n> Greg KH <gregkh@linuxfoundation.org> writes:\n> > The number of people this affects right now is only one (me), given that\n> > the offending file is not in Linus's tree right now, so he doesn't have\n> > issues with uploading new releases.\n> \n> As a tree grows larger over time, it may be just a matter of time\n> for somebody else to be hit by another deep path, though.\n\nI agree, and over time, everyone will have updated to a version of git\nnewer than 1.8.2.1 so we all will be fine again :)\n\nthanks,\n\ngreg k-h\n"}]}