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

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

"J. Bruce Fields" [off-list ref] writes:

quoted

On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:

quoted

On Mon, 17 Dec 2007, J. Bruce Fields wrote:

quoted

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.

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.