Re: [PATCH v2 00/16] First class shallow clone

From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Date: Jul 24, 2013, 08:30 UTC
Message-ID: <CAA01CsrHaCGrt37r4bn1OBY-=skJXZBHOaPH=Gsz-8BCmiW6jQ@mail.gmail.com>
In-Reply-To: <CACsJy8AzFogspTih4mJoog6MGEWgmuae2KmFysQ0-siCvfH2yA@mail.gmail.com>

(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:

Show 12 quoted lines

> 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.

-- 
Piotr Krukowiecki