Does long commit history make cloning git repository slow?-CodePudding

I have a git repository with a very long commit history. For the sake of simplicity let's say my old repo only contains the master branch with commits COMMIT-1...COMMIT-10000. I was wondering if I could reduce the time needed for cloning and the required space for the local repo if I created a "copy" of the given repository by creating a large "squashed" commit (COMMIT 1*) that includes all the modifications so far.

Sketch of the modification:

CURRENT REPO     ----->     NEW REPO
COMMIT-10000                COMMIT-1*
     |                  
    ...      
     |
  COMMIT-1

Would this actually improve the cloning speed or the memory requirement?
Are there any generally applicable solutions to improve these things?

Thanks in advance :)

CodePudding user response：

The commits in a repository are the history; more commits = more history = more overall data = more overall time. So: yes, if you make a new repository with only one commit holding one snapshot of all the files, this will always be at least a little bit smaller than your old repository with 10,000 snapshots holding all the files.

How much smaller, and how much faster it would become to use, are very difficult to predict. Because commits re-use the files from earlier commits as much as possible, it could be only very slightly smaller. Because they only re-use files from earlier commits as much as possible, it could be 10,000 times smaller, or more. For instance, suppose the first commit contains 10,001 different files, and every subsequent commit-as-snapshot removes one file, retaining the remaining files. Then the new repository will have one file in one snapshot, while the old commit has 10,001 files in 10,000 snapshots.

In practice, the only way to find out is to try it.