Re: [PATCH 09/19] documentation: add documentation for the bitmap format

On Wed, Oct 30, 2013 at 11:23 AM, Shawn Pearce [off-list ref] wrote:

On Wed, Oct 30, 2013 at 7:50 AM, Jeff King [off-list ref] wrote:

quoted

On Fri, Oct 25, 2013 at 01:47:06PM +0000, Shawn O. Pearce wrote:

quoted

I think Colby and I talked about having additional optional sections
in this file, but Colby didn't want to overcomplicate the format early
on. So v1 is probably not very extensible and we may have to go to v2
to safely create an extension with the name hash cache used in this
series.

Given that the JGit v1 bitmap format has been shipping since JGit 3.0
and in Gerrit Code Review 2.6, its in use in the wild. So we aren't
going to go back and redefine v1.

I don't think either course of action affects how JGit in the wild will
react. If we add a new flag to v1, existing JGit barfs. If we move to
v2, existing JGit barfs.  In either case, the simplest fix for JGit is
to ignore the new section.

Fair point. Then we can use v1 with the flag for now, JGit will barf and...

Shawn, I'm proposing the following patch to JGit (actually Kevin is,
because I don't have the CLA, but whatevs):

https://git.eclipse.org/r/#/c/17894/

It's a very small change (using an "and" to check for the flags on the
bitmap instead of a switch), but I think it's very clean. In the
spirit of "Be conservative in what you send, be liberal in what you
accept", this patch lets JGit read V1 bitmaps emited from git.git
*even* if they have the extended Name Cache extension, and has no
effect on any JGit bitmap that has been generated up to date, or any
JGit bitmap generated from git.git without name caches.

I don't think it *changes* the semantics of the bitmap V1 format,
because with only one bit value set so far, those semantics weren't
really there, and it'll allow newer versions of JGit to never barf.

Love,
vmg