On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> wrote: > (resending, as my phone mail client decided to send it in html, sorry > about that) > > On Wed, Jul 24, 2013 at 3:57 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley <philipoakley@xxxxxxx> wrote: >>> There have been comments on the git-user list about the >>> problem of accidental adding of large files which then make the repo's foot >>> print pretty large as one use case [Git is consuming very much RAM]. The >>> bigFileThreshold being one way of spotting such files as separate objects, >>> and 'trimming' them. >> >> I think rewriting history to remove those accidents is better than >> working around it (the same for accidentally committing password). We >> might be able to spot problems early, maybe warn user at commit time >> that they have added an exceptionally large blob, maybe before push >> time.. > > I can imagine a situation where large files were part of the project > at some point in history (they were required to build/use it) and > later were removed because build/project has changed. > > It would be useful to have the history for log/blame/etc even if you > could not build/use old versions. A warning when checking > out/branching such incomplete tree would be needed. That's what shallow clone is for. You fetch the latest (not including old large blobs) and work on top. For archaeology, make a full clone. Or do you mean log/blame/etc other paths that don't touch big blobs, and the clone is still incomplete? -- Duy -- 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