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

From: Philip Oakley <philipoakley@iee.org>
Date: Jul 24, 2013, 07:38 UTC
Message-ID: <3E185895A3E14127A858979373F76766@PhilipOakley>
In-Reply-To: <CACsJy8AzFogspTih4mJoog6MGEWgmuae2KmFysQ0-siCvfH2yA@mail.gmail.com>

From: "Duy Nguyen" <pclouds@gmail.com>
Sent: Wednesday, July 24, 2013 2:57 AM

Show 10 quoted lines

> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley <philipoakley@iee.org> 
> wrote:
>> In some sense a project with a sub-module is a narrow clone, split at 
>> a
>> 'commit' object.
>
> Yes, except narrow clone is more flexible. You have to decide the
> split boundary at commit time for sub-module, while you decide the
> same at clone time for narrow clone.
>

True. It was the thought experiment part I was referring to.

Show 14 quoted lines

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

Again, it was a thought experiment which related to a recent git-user list comment. I'd expect a real use case could be a team where one member who is preparing documentation adds a [large] video to his branch and others then get a bit concerned when they try to track it / pull it as they really don't want it yet. The guy may have many versions on the central repo before a final rebase has a single compressed version. Colleagues may want to review the text surrounding it but not pull the video itself. (remembering 50 % of 'idiots' are twice as dumb as the average... ;-)

>
> The "Git is consuming very much RAM" part is not right. We try to keep
> memory usage under a limit regardless of the size of a blob. There may
> be some cases we haven't fixed yet. Reports are welcome.

I think this was a Windows user, but reports do pop up every now and again. Some times its disc pressure, or just perceived slowness (from others)

> -- 
> Duy

Philip