Duy Nguyen <pclouds@xxxxxxxxx> napisał: >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? Yes, for example if large files were removed recently the last-n-commits-shallow would be useless from blame/log POV. -- 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