Re: [PATCH v2 00/16] First class shallow clone
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 24, 2013, 10:35 UTC
- Message-ID
- <CACsJy8BouRHZAmCKQ779iAUiEX-rK9_FSrxu9V-bn6MCBTBEzg@mail.gmail.com>
- In-Reply-To
- <CAA01CsrHaCGrt37r4bn1OBY-=skJXZBHOaPH=Gsz-8BCmiW6jQ@mail.gmail.com>
On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki <piotr.krukowiecki@gmail.com> wrote:
Show 24 quoted lines
> (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@gmail.com> wrote: >> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley <philipoakley@iee.org> 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