git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Steven Grimm <koreth@midwinter.com>
To: Nicolas Pitre <nico@cam.org>
Cc: Sam Vilain <sam@vilain.net>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Junio C Hamano <junkio@cox.net>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] Add --no-reuse-delta option to git-gc
Date: Sun, 10 Jun 2007 23:20:08 -0700	[thread overview]
Message-ID: <466CE998.9000706@midwinter.com> (raw)
In-Reply-To: <alpine.LFD.0.99.0706102144080.12885@xanadu.home>

Nicolas Pitre wrote:
>
> It won't happen for a simple reason: to be backward compatible with 
> older GIT clients.  If you have your repo compressed with bzip2 and an 
> old client pulls it then the server would have to decompress and 
> recompress everything with gzip.  If instead your repo remains with gzip 
> and a new client asks for bzip2 then you have to recompress as well 
> (slow).  So in practice it is best to remain with a single compression 
> method.
>   

Not that I really think this is all that important (my original question 
was more out of curiosity than anything) but I don't think those are 
really issues.

Even with a better compression scheme, nobody would want to remove gzip 
support; if you are creating a repo that needs to be compatible with old 
clients -- and of course not all repositories need that -- you'd just 
configure it to use gzip (or more likely, *not* configure it to use the 
other method.) There are already options whose documentation says, 
"Don't enable this if you want your repo to be accessed by git clients 
older than version X." In other words, git already has an established 
approach for adding new non-backward-compatible features. Some projects, 
e.g. internal corporate ones, can mandate that everyone upgrade their 
clients, and more importantly, once any new git feature has been out for 
a long enough time, even public projects can reasonably say, "You need 
version X to access our repo." If alternate compression were introduced 
today, in five years would anyone care that there'd be some ancient, 
ancient clients that couldn't use it?

And since the hypothetical new client would have support for both 
compression types, pulling from a gzip-based repo could be accomplished 
totally transparently; you could, one assumes, even pull from a gzip 
repo and pack locally using the other scheme if you felt like it.

-Steve

  reply	other threads:[~2007-06-11  6:20 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08  2:54 [PATCH] Add --no-reuse-delta, --window, and --depth options to git-gc Theodore Ts'o
2007-05-08  3:13 ` Nicolas Pitre
2007-05-08  3:21   ` Theodore Tso
2007-05-08  3:38     ` Dana How
2007-05-08  4:43     ` Junio C Hamano
2007-05-08 13:46       ` Nicolas Pitre
2007-05-08 13:28 ` [PATCH] Add --no-reuse-delta, --window, and --depth options to Theodore Ts'o
2007-05-08 13:28   ` [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50 Theodore Ts'o
2007-05-08 13:28     ` [PATCH] Add --no-reuse-delta option to git-gc Theodore Ts'o
2007-05-08 15:35       ` Nicolas Pitre
2007-05-09  5:05       ` Daniel Barkalow
2007-05-09  8:15         ` Junio C Hamano
2007-05-09  9:02           ` Steven Grimm
2007-05-09 11:35             ` Other compression?, was " Johannes Schindelin
2007-05-09 15:15             ` Junio C Hamano
2007-05-09 19:10             ` Shawn O. Pearce
2007-06-10  7:40               ` Sam Vilain
2007-06-11  1:51                 ` Nicolas Pitre
2007-06-11  6:20                   ` Steven Grimm [this message]
2007-06-11  6:31                     ` Shawn O. Pearce
2007-06-11 10:20                   ` Johannes Schindelin
2007-06-11 14:01                     ` Nicolas Pitre
2007-06-11 21:40                       ` Johannes Schindelin
2007-05-09 19:48           ` [PATCH] Add --aggressive option to 'git gc' Theodore Tso
2007-05-09 20:19             ` Junio C Hamano
2007-05-09 22:22               ` Theodore Tso
2007-05-10  7:38             ` Junio C Hamano
2007-05-08 15:38     ` [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50 Nicolas Pitre
2007-05-08 16:30       ` Theodore Tso
2007-05-08 16:49         ` Johannes Schindelin
2007-05-08 18:09           ` Theodore Tso
2007-05-08 18:46             ` Nicolas Pitre
2007-05-09 13:49               ` Theodore Tso
2007-05-09 14:17                 ` Johannes Schindelin
2007-05-08 17:07         ` Dana How
2007-05-08 17:35         ` Nicolas Pitre
2007-05-09  5:03           ` Junio C Hamano
2007-05-08 15:30   ` [PATCH] Add --no-reuse-delta, --window, and --depth options to Nicolas Pitre
2007-05-08 21:12     ` Junio C Hamano
2007-05-08 23:59       ` Nicolas Pitre

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=466CE998.9000706@midwinter.com \
    --to=koreth@midwinter.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=nico@cam.org \
    --cc=sam@vilain.net \
    --cc=spearce@spearce.org \
    --cc=tytso@mit.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).