2009/5/2 Björn Steinbrink <B.Steinbrink@xxxxxx>: >> As I've stated: "address", "pointer", and "handle" are an analogy to >> terminology that has been around for ages. In fact, another name for >> "pointer" is "reference". > > AFAIK a pointer is just one kind of reference. C++ references are > another kind... Actually, a C++ reference is a pointer with restrictions (AFAIK). > A reference is one piece of data that lets me access a different > piece of data. The key word there is 'access', which implies some kind of storage (or memory). > > And there are probably plenty of examples where you could apply that > analogy, yet nobody (I know) does. Arrays, database tables, ... Well, this terminology is certainly used with arrays in C, because array elements can be accessed with pointers. Also, databases use a much different scheme for addressing information than does memory. However, you're probably correct that pointer terminology doesn't exist much outside of C/C++ and older languages (Ada?). > > And "memory" usually means "RAM" to me, not "WORM"-memory (well, > actually, you can also delete and then rewrite, but not modify). Well, I don't see how Random Access Memory really conflicts. One certainly can access objects in the object memory/store randomly. The main difference is that the computer store is addressed by location, wheras the git store is addressed by content. Also, I would say that conceptually deletion is an implementation detail. Because git's object store is content addressable, one could think of it as already containing all possible objects (of course, I'm assuming that the 160-bit hash is also an implementation detail; an infinite number of objects implies infinitely large addresses, though the nonsignificant zeros could be disregarded as with real numbers or something. I don't know, I'm making this up as I go :-D). That the git tools ever complain no such object exists is an implementation detail resulting from our finite storage in reality. > So the > analogy would even hurt my mental model (just like the "commit --amend" > command might be consider harmful, because it actually creates a new > commit, but some users actually think the original commit is modified). Actually, this is why it's so important to have the underlying concepts at hand. Understanding that objects are simply addressed by content (that is, objects are immutable) completely extirpates this kind of confusion. >> >> So, a pointer variable's value is an object address that is the >> >> location of an object in git 'memory'. I think using this approach >> >> would make things significantly more transparent. >> > >> > But then HEAD would be a pointer pointer variable (symbolic ref), unless >> > you have a detached HEAD. >> >> We call those handles. > > Isn't a handle basically an opaque/abstract reference, at least in > "modern" usage? Symvolic references aren't. The user is free to create > and manipulate them, and gets full access to the things referenced by > them. And saying that HEAD is a reference, that might be symbolic is > IMHO by far easier to understand than saying that HEAD might be a > pointer or a handle. Fair enough. Call them symbolic pointers; however, I don't really see the problem with pointer pointers. In any case, I *think* my point is that it's important to understand that git uses content addressing; at first I was emphatic about the idea of 'addressing', so I went with pointer terminology (which works quite well, in my opinion). However, I think the 'content' part is more important, which is why 'object hash' is loads better than 'object name' or 'object id'. Also, at least the documentation could say that 'objects are addressed by their hashes', which says a whole lot in one quick sentence about how git works. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html