Re: [doc] User Manual Suggestion

[Michael Witten <mfwitten@gmail.com>]

On Fri, Apr 24, 2009 at 16:38, Jeff King <peff@peff.net> wrote:
> On Fri, Apr 24, 2009 at 05:34:00PM -0400, Daniel Barkalow wrote:
>
>> I'd say that blobs and trees are an implementation detail of "the full
>> content of a version of the project", not something conceptually
>> important. Likewise, the date representation used in commits isn't
> ...
> No, that isn't critical for understanding how _commit_ operations work,
> but I think that is exactly the sort of conceptual knowledge that let
> people use git more fully.

I think the key conlusion here is that the main concepts are *objects*
and references to those objects. One type of object is not necessarily
more low-level or high-level than another type of object; each type of
object is the most important type of object for a particular task in
or view of the git world.

> I disagree. I think it's important to note that trees and blobs have a
> name, and you can refer to them. Once you know that, the fact that you
> can do:
>
>  git show master
>  git show master:Documentation
>  git show master:Makefile
>
> just makes sense. You are always just specifying an object, but the type
> is different for each (and show "does the right thing" based on object
> type).

In fact, I think it's important to note that the notation:

    git show master:Makefile

actually involves a translation from a Unix filesystem address to a
git object address that is then used to find the relevant data.

In fact, I think masking this kind of thing with a catch-all word
'reference' is a bad idea. Rather than being hidden, it should be
exposed: I think it would be beneficial to use the word 'address'
rather than 'reference' when talking about the SHA-1 names. Then HEAD
could be called a pointer variable, etc.

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.