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

[Piotr Krukowiecki <piotr.krukowiecki@gmail.com>]

Duy Nguyen <pclouds@gmail.com> napisał:
>On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki
><piotr.krukowiecki@gmail.com> 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@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?


Yes, for example if large files were removed recently the last-n-commits-shallow would be useless from blame/log POV.