New answers tagged file-systems
File system operations are actually often at a coarser granularity than the changes that VCS tracks. A file may be over-written in a single operation, when only a line has really been changed. Other times, the file system operations are too fine-grained and miss the big picture. Someone may "copy" a file and then rewrite everything except the copyright ...
You've misunderstood because the filesystem transaction log is a very temporary beast, it does not hang around long enough to be used for history (at least in no filesystem I know of). But otherwise, yes - its a valid principle. The VCS log would be the only log you have however. It cannot be transported though as it is not a transaction log, it a 'living' ...
There are two reasons why this is desirable. Directories cannot be arbitrarily large. E.g. some (reasonably modern!) filesystems are limited to 32000 entries in a single directory. The number of commits in the Linux kernel is in that order of magnitude. Subdividing the commits by their first two hex digits limits the top-level size to 256 entries. The ...
There are some filesystems and/or filesystem implementations and/or libc implementations where performance degrades with large numbers of directory entries.
These 256 bucket allow git to store larger repositories on file systems that limit the number files in a directory and provide descent performance on file systems that become slower with directories containing many files.
It is possible to put all the files in one directory, though sometimes that can become a bit large. Many file systems have a limit. You want to put a git repository on a FAT32 formatted drive on a USB stick? You can only store 65,535 files in a single directory. This means that it is necessary to subdivide the directory structure so that filling a single ...
Top 50 recent answers are included