On Mon, Dec 17, 2007 at 02:17:01PM -0800, Junio C Hamano wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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. > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
