On Sat, May 31, 2014 at 5:52 AM, Bartosz DziewoĆski
<matma.rex(a)gmail.com>
wrote:
I don't like this idea, for the same reasons
that other have already
given. Grafting histories with git-replace might be viable, but it'd still
be clunky and non-intuitive.
Ok, fair enough. Everyone's made some really good points so let's drop
the
idea of dropping our history.
However I think we should continue to discuss ways to contain the repo size
going forward. That, combined with some aggressive repacking and dropping
of refs/changes/* (when we move to Phabricator) should help get it under
control.
Why don't we just suggest that people use
shallow clones? Git supports
pushing from and pulling to them since 1.9, and while Gerrit doesn't accept
pushes from them (or at least it didn't when I just tried), I see no reason
why Phabricator would have any issues if it only works on diffs anyway, not
commits.
This is also a good idea.
-Chad
Chad, thanks for bringing this up. I'm especially grateful that you
named the target repo size at 30 to 35 MB -- it makes this more concrete.
I think some more numbers/facts might help us make the right tradeoffs
here to think about ways to contain the repo size going forward -- like:
* Antoine said "My repacked copy of core is 270MB" and we have some
disagreement about whether that's okay. Is there a max size we want to
avoid getting to?
* A bigger repo is obviously slower to download in full; is it also
slower to search or otherwise work with? How much slower? Most of our
developers are probably not on SSDs yet.
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation