From: Felipe Contreras <felipe.contreras@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jakub Narebski <jnareb@gmail.com>,
Mark A Rada <marada@uwaterloo.ca>,
git@vger.kernel.org
Subject: Re: Add Gitweb support for LZMA compressed snapshots
Date: Sat, 1 Aug 2009 13:10:58 +0000 [thread overview]
Message-ID: <94a0d4530908010610n31261414yc08060f3de9c115f@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0908011431060.8306@pacific.mpi-cbg.de>
On Sat, Aug 1, 2009 at 12:34 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 31 Jul 2009, Felipe Contreras wrote:
>
>> On Thu, Jul 30, 2009 at 8:43 AM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> >
>> > On Thu, 30 Jul 2009, Jakub Narebski wrote:
>> >
>> >> BTW. I wonder if it would be good idea to add support for this format
>> >> directly to git-archive... OTOH it would mean additional dependency.
>> >
>> > I don't think it would be a good idea; we do not have bzip2 support
>> > either.
>>
>> bzip2 has no advantages whatsoever.
>
> Bzzzzt. Wrong. Just because you cannot see them does not mean it has no
> advantages.
All right, most the time you compress once, and multiple people
uncompress multiple times. Therefore the path that should be optimized
is the decompression, that leaves bzip2 out of the picture.
You can think of advantages of bzip2 in more esoteric cases where the
compression time is also important. I don't think that's the case
here. Actually it might be if gitweb is not caching the tarballs, but
if that's the case I wouldn't say it's an advantage of bzip2.
>> AFAIK xz is superior to other formats and it would be nice to see git
>> make a technological stance encouraging xz.
>
> Bzzzt. Wrong again. Git's mission in life is not to encourage one
> compression over another.
Git's mission in life is not promoting asciidot either, but it's doing
that unintentionally by merely using it.
> If at all, the only compression Git actually does promote in a sense is
> zlib compression.
>
>> > The only reason we have inbuilt gzip and zip support is because the
>> > format is so similar to Git's own compression.
>>
>> Personally I don't see the point of having zip support.
>
> Personally, I see the point of having zip support. It makes things easy
> for Windows users. And it's an established format, much more so than
> tar.gz.
Windows can't extract .tar.gz?
--
Felipe Contreras
next prev parent reply other threads:[~2009-08-01 13:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 5:48 Add Gitweb support for LZMA compressed snapshots Mark A Rada
2009-07-30 7:44 ` J.H.
2009-08-01 7:43 ` Alex Riesen
2009-08-01 14:34 ` Dmitry Potapov
2009-08-01 14:38 ` André Goddard Rosa
2009-08-01 14:58 ` Jim Meyering
2009-08-01 18:51 ` Alex Riesen
2009-07-30 7:52 ` Johannes Schindelin
2009-07-30 8:31 ` Jakub Narebski
2009-07-30 8:43 ` Johannes Schindelin
2009-07-31 15:45 ` Felipe Contreras
2009-08-01 12:34 ` Johannes Schindelin
2009-08-01 13:10 ` Felipe Contreras [this message]
2009-08-01 14:04 ` Erik Faye-Lund
2009-08-01 16:07 ` Mark A Rada
2009-08-01 21:39 ` Erik Faye-Lund
2009-08-01 14:13 ` Dmitry Potapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94a0d4530908010610n31261414yc08060f3de9c115f@mail.gmail.com \
--to=felipe.contreras@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=marada@uwaterloo.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).