Re: [PATCH] provide advance warning of some future pack default changes

From: J. Bruce Fields <bfields@fieldses.org>
Date: Dec 17, 2007, 22:30 UTC
Message-ID: <20071217223055.GI13515@fieldses.org>
In-Reply-To: <7vtzmh55lu.fsf@gitster.siamese.dyndns.org>

On Mon, Dec 17, 2007 at 02:17:01PM -0800, Junio C Hamano wrote:

Show 21 quoted lines

> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> >> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> >> 
> >> > By the way, just as a data point: I do keep some git repositories on
> >> > NFS, and access them from multiple machines with different git versions
> >> > (not on purpose--it's just that the machines don't all run the same
> >> > distro, so it'd be extra work to give them all the same version).  I
> >> > don't use anything older than 1.5.0.  If the repository became unusable
> >> > on one of those machines without warning it'd be annoying.
> >> 
> >> What the v1.5.5 release notes will say is that you'll have to set 
> >> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.  
> >
> > Is there any reason not to make pack.indexversion=1 the default (for
> > preexisting repositories at the very least) and suggest in the release
> > notes that people set something else if they want the features the new
> > version provides?
> 
> That's a judgement call.

Sure. And I'm totally unfamiliar with the details here, so don't my let my judgement weigh too heavily.

Show 8 quoted lines

> Pack-idx format v2 is by design much safer in the face of bitflip (do we
> have a test case to make sure this is indeed true?).  But from the end
> user's point of view, all the usual "I do not want to be forced to
> update that old box I do not want to touch" applies.
> 
> And the people who needs to suffer from the dilemma are only the ones
> who access a single repository across NFS with git from different
> vintage.

Hm.  We tell people to set up public repo's by doing something like:

	git clone --bare ~/proj proj.git
	touch proj.git/git-daemon-export-ok
	scp -r proj.git example.com:

Is that going to hit the same problem if the public server has an older git version? (Servers do tend to be on longer upgrade cycles; the public server I use was on something 1.4ish till about a month ago.)

--b.