On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki
<piotr.krukowie...@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 <pclo...@gmail.com> wrote:
>> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley <philipoak...@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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to