2 ms·
Hmmm I'm just trying to wrap my head around this. It sounds like git can't store 0-length data, but, it stores empty files (data, wrt your smalltalk example) j
by zackmorris 13y ago
Hmmm I'm just trying to wrap my head around this. It sounds like git can't store 0-length data, but, it stores empty files (data, wrt your smalltalk example) just fine. So that must mean that it's not distinguishing between files and directories. It's probably also not storing other metadata like executable or permissions flags, labels (like on Mac OS), both creation AND modification dates, etc etc (but that's beyond the scope of this discussion).
Does anyone know if git stores the path separator as part of the path? For example does it store a path reference as a string "/var/log" or as a list {"var", "log"} internally? That gives us 2 options:
1) If git DOESN'T store the path separator, then that means there's no way to represent a directory as "var/", to signify that it's a directory (because a file could contain the path separator character). If that's the case, then perhaps I was wrong to call it a political decision. An argument can be made for purity here.
2) If git DOES store the path separator inside a path string, then a mistake was made, because there was a chance there to distinguish between a directory "var/" and a file "var". Sometimes I refer to these types of mistakes as political decisions, for example if it's easier to make the mistake than work through a full implementation. I can't imagine that git works this way, but I'm throwing it out there because I have seen stranger things.
- nnethercote 13y agoGo read a git tutorial. It's a faster way to learn than asking random questions of strangers on a tech news site.
- zackmorris 13y agoAfter I posted that comment, I remembered that I had read one a couple of years ago and it explained trees and blobs. Looking at the tree structure now though, I can't see any reason why a leaf has to be a blob instead of a tree. So without some new rationale, I have to come to the conclusion that ignoring empty directories was a political decision. Perhaps I missed something in how the hash is computed, for example if the node's name wasn't part of the hash, then empty directories would have no effect on it, which would mean the same hash could represent different directory structures, which would be incorrect. But that can't be right, because git can store empty files. This all means that git can't represent an arbitrary directory structure. That's a big deal, because it can't be used to say, incrementally back up a hard drive without help. That's all well and good if its main use is version control, but I'll never look at it quite the same way again.