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
> 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.

If we want to define a v2 format and make it clear how to add optional
sections, that's fine. But what I really want to avoid is a big v2
bikeshedding discussion where other features get added because it's a
version bump. This feature has been a long-time coming, and I'd like to
at least get us on par with JGit's v1 bitmaps. It's a big series, and I
fear that v2 discussions would end up as a distraction.

If that means dropping the name-hash cache from the series, so be it
(that's part of why I pulled it out into its own patch at the end). We
could also make it optional with a documentation warning that existing
JGit will not like the resulting bitmap files. In practice, I do not
expect it to be a big deal, as most sites will not mix-and-match serving
from the two implementations (though you might repack with C git and
serve with JGit, which means "off" would be the sane default for the

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

Reply via email to