Rationale for symlinking does not seem valid

[QuLogic]

The rationale given is "thus reducing the overall repository size to those that need to clone the repository", but one of the old taglines for git is it's the "stupid content tracker", key word being content. Having multiple copies of the same file does not substantially change the size to be cloned:

mkdir separate
git init separate
cd separate
mkdir a b c
# This is the largest file in the repo at ~7M:
cp ../cartopy/docs/v0.15/examples/wmts_time_00_00.pdf a/
cp ../cartopy/docs/v0.15/examples/wmts_time_00_00.pdf b/
cp ../cartopy/docs/v0.15/examples/wmts_time_00_00.pdf c/
git add a b c
git commit -m 'Initialize'
git gc --aggressive
cd ../

mkdir symlinked
git init symlinked/
cd symlinked
mkdir a b c shared
cp ../cartopy/docs/v0.15/examples/wmts_time_00_00.pdf a/
cp ../cartopy/docs/v0.15/examples/wmts_time_00_00.pdf b/
cp ../cartopy/docs/v0.15/examples/wmts_time_00_00.pdf c/
../tools/symlink_common.py . --shared-dir shared
git add a/ b/ c/ shared/
git commit -m 'Initialize'
git gc --aggressive
cd ..

This gives:

$ du -hsc */.git
7.3M	separate/.git
7.3M	symlinked/.git

Symlinking might be useful to reduce checkout size though, so maybe that's what it should say?

[pelson]

I agree (and was looking for a similar comment I made recently, but couldn't find it). I'm mostly responsible for this - and completely accept that the statement is incorrect.

I'm open to fixing the rationale, or simply starting to cease using the symlinking stuff. Any preference @QuLogic?

[QuLogic]

No preference really. There might be some savings in local checkouts, but I have not measured it.