Re: [doc] User Manual Suggestion

From: Michael Witten <mfwitten@gmail.com>
Date: Apr 24, 2009, 22:18 UTC
Message-ID: <b4087cc50904241518w625a9890vecdd36bb937e76d5@mail.gmail.com>
In-Reply-To: <20090424213848.GA14493@coredump.intra.peff.net>

On Fri, Apr 24, 2009 at 16:38, Jeff King <peff@peff.net> wrote:

Show 9 quoted lines

> 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.

Show 11 quoted lines

> 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.