On Sun, Oct 15, 2006 at 08:39:56PM CEST, Sean wrote: > On Sun, 15 Oct 2006 20:23:03 +0200 > Petr Baudis <pasky@xxxxxxx> wrote: > > > (BTW, yes, grafting the old history could help this time, but it is a > > hack and not a good long-term solution - it is just putting the real > > solution away until the project history will re-grew. Periodical > > regrafting is even worse hack, since at that moment you break > > fast-forwarding and this kind of "restarting the history" breaks deep > > into the Git distributiveness.) > > But is there a better practical solution he can use today? I don't think > there is. And the experience of the Linux kernel has shown that it's not > really all that big a problem. You even made a nice script to help people > do it! ;o) > > It's probably not the solution that should be used _next_ time the repository > grows too big, but it sure seems like the correct solution this time around. > Not many people will want all that old history anyway (10+ years as i recall?). Well I'm not saying it's the incorrect solution today, only that we won't get around the problem by suggesting grafting forever. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) - 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