Splitting off old history to ancillary repo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A project I've inherited has a codebase ~500KB in size. However, in
early history some large binary blobs were committed to the repo.
We've gotten rid of those, and they are not interesting to current
development. But an initial checkout still has to retrieve 60MiB, when
I'm sure the recent (and interesting) history fits in less than 1MB.

What is the state of grafts from a "keeping the repo mostly
transparently usable for newcomers" POV? Is there a new mechanims I
should look at?

Do we have a documented "here's how you split your repo with minimal
downsides to end users"? If you give me enough hints I could write it
:-)

The repo in question is http://dev.laptop.org/git?p=projects/xs-config;a=summary

cheers,


m
-- 
 martin.langhoff@xxxxxxxxx
 martin@xxxxxxxxxx -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux