In my opinion repacking is just a little optimization for saving some storage on the disc and not a fundamental concept of git
Git would work pretty well without this function. Git never store the exact same object twice. So if you have two commits which only differs by one file change, every file except the one who's changes is used again for the second commit. (underneath it's like a key value store which uses the hole content to generate a unique key (sha-1)).
The changing file will be stored a second time here as a complete new file. Git does does not track file changes. So, if this file is big it could be a little a waste of disc space (normally not so important today). But to make such situation more efficient, you can use the repack feature.
Hi, I’m Steffen. I create Embedded software for a living.
I always strive to improve the quality of my code by studying new methods, paradigms and technologies.
In my opinion repacking is just a little optimization for saving some storage on the disc and not a fundamental concept of git
Git would work pretty well without this function. Git never store the exact same object twice. So if you have two commits which only differs by one file change, every file except the one who's changes is used again for the second commit. (underneath it's like a key value store which uses the hole content to generate a unique key (sha-1)).
The changing file will be stored a second time here as a complete new file. Git does does not track file changes. So, if this file is big it could be a little a waste of disc space (normally not so important today). But to make such situation more efficient, you can use the repack feature.
You‘re right. Repacking is just an optimization.
Speaking in the naive analogy, you don‘t need to compress the backup folders after all. It‘s an optimization to save disk space.
As suggested in a comment to the original article, this analogy might a bit misleading...