3 ms·

Man, I didn't know that git couldn't store empty directories or check out subtrees. Those are pretty substantial shortcomings. Up till now I assumed that git

Man, I didn't know that git couldn't store empty directories or check out subtrees. Those are pretty substantial shortcomings. Up till now I assumed that git was sort of the bittorrent way to store a filesystem and was close to ideal. But those issues are causing me to reevaluate. Not storing directories is definitely a political decision, so by default I oppose it (Apple makes these kinds of unilateral decisions all the time, to me it's the ugly side of programming). I'm hopeful that perhaps the subtree issue has something to do with all of the hashes being nested and maybe there is a workaround (perhaps git needs placeholders when the files aren't present?) I also didn't realize that there is no revision number in git, but since we can use the hash string I'm ok with it. Conceptually they are both just keys anyway. The chronological order of the hashes is encoded in their structure, so hopefully git makes it easy to retrieve the list.

Tuna-Fish 13y ago
> Not storing directories is definitely a political decision, so by default I oppose it It's a technical decision. Git doesn't store files or directories. It stores blobs of data identified by arbitrary textural identifiers. These identifiers tend to be paths, but they need not be, for example for a smalltalk-like system. There are advantages to this representation, for example when tracking changes across refactors that merge/split code files.
- 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 ago
    Go read a git tutorial. It's a faster way to learn than asking random questions of strangers on a tech news site.
    - zackmorris 13y ago
      After 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.
josephlord 13y ago
Just add a file. I seem to recall that an empty .gitkeep is traditional.

Tuna-Fish 13y ago

> Not storing directories is definitely a political decision, so by default I oppose it It's a technical decision. Git doesn't store files or directories. It stores blobs of data identified by arbitrary textural identifiers. These identifiers tend to be paths, but they need not be, for example for a smalltalk-like system. There are advantages to this representation, for example when tracking changes across refactors that merge/split code files.

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 ago
  Go read a git tutorial. It's a faster way to learn than asking random questions of strangers on a tech news site.
  - zackmorris 13y ago
    After 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.

josephlord 13y ago

Just add a file. I seem to recall that an empty .gitkeep is traditional.