Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

From: Greg KH <gregkh@linuxfoundation.org>
Date: Feb 4, 2013, 00:45 UTC
Message-ID: <20130204004512.GB6243@kroah.com>
In-Reply-To: <7vr4l1gqv8.fsf@alter.siamese.dyndns.org>

On Thu, Jan 31, 2013 at 10:16:27AM -0800, Junio C Hamano wrote:

Show 21 quoted lines

> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:
> >
> >> How about fixing kup to teach the "let's cheat and let the other end
> >> run 'git archive', if the resulting archive and GPG signature
> >> locally created does match, we do not have to transfer the tarball
> >> itself" trick a fall-back mode that says "but if the signature does
> >> not match, then transfer the bulk used to create the signature to
> >> the remote anyway".  This fallback can and should of course be
> >> useful for the compressed patch transfer.
> >
> > Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up
> > doing lots of kernel releases while traveling), would be a horrible
> > change.  I'd rather just keep using the same older version of git that
> > kernel.org is running instead.
> 
> Then how about fixing kup to try both versions of Git?  There will
> be people who run different versions of Git anyway, and kup should
> not be preventing Git from helping people on other platforms, or
> improving its output in general.

I think the combinations of different versions of git that would have to be installed on kernel.org to handle stuff like this as things change over time, wouldn't be worth it.

The number of people this affects right now is only one (me), given that the offending file is not in Linus's tree right now, so he doesn't have issues with uploading new releases.

So I'll just work to ensure I have the same version of git in place if I ever run into this problem again. Or just break down and do full-compressed tarballs instead, if I'm in a place where I have a good network connection.

thanks,

greg k-h