"Shawn O. Pearce" <spearce@xxxxxxxxxxx> wrote:
> Obviously this series has a heavy hand on sha1_file.c,
> builtin-pack-objects.c, builtin-unpack-objects.c, index-pack.c.
> But it will also start to hit less obvious places like commit.c
> and tree-walk.c as we start to support walking the encoded objects
> directly.
>
> Given the huge size of the series, and the amount of effort we are
> tossing into it, and the fact that I'm trying to make it pu-ready by
> early next week, we would appreciate it if folks could keep changes
> to the above mentioned files limited to critical bug fixes only. :)
After rereading this message[*1*] several hours later, and also
just learning that Nico will be taking a probably much deserved
vacation soon, my concept of getting this series ready for Junio's
pu-branch by next week is just far too aggressive to be practical.
Nico and I have had a lot of off-list discussion about possible
things we can do with the various encodings and what types of
runtime optimizations they could actually support. These have
created a lot of cases we really need to explore and confirm as
useful or verify as not-useful before submitting a series to Junio.
Improving the packfile format is a relatively non-trivial change;
we would hate to see people actually start to use a pack v4 file
only to have the encoding change *again* in the near future due to
a better optimization being selected and employed.
That said, I would like to keep the development openly visible
(hence its on repo.or.cz) and would like to encourage people to send
ideas, suggestions, etc. I think it is very helpful when everyone
knows what is actively being worked on, so they can contribute to
projects they may be interested in, and avoid causing conflicts
with those projects when possible. ;-)
*1*: Yea, I really do read my own email when vger finally gets
around to bouncing it back to me. ;-)
--
Shawn.
-
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