From: "Duy Nguyen" <pclo...@gmail.com>
Sent: Wednesday, July 24, 2013 2:57 AM
On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley <philipoak...@iee.org>
In some sense a project with a sub-module is a narrow clone, split at
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.
There have been comments on the git-user list about the
problem of accidental adding of large files which then make the
print pretty large as one use case [Git is consuming very much RAM].
bigFileThreshold being one way of spotting such files as separate
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
Again, it was a thought experiment which related to a recent git-user
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
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
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