On Wed, Oct 30, 2013 at 11:23 AM, Shawn Pearce <spea...@spearce.org> wrote:
> On Wed, Oct 30, 2013 at 7:50 AM, Jeff King <p...@peff.net> wrote:
>> On Fri, Oct 25, 2013 at 01:47:06PM +0000, Shawn O. Pearce wrote:
>>> 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
>>> 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):
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html