Re: [PATCH] update README and #include in git.txt

[David Greaves <david@dgreaves.com>]

Petr Baudis wrote:

>Dear diary, on Thu, May 12, 2005 at 11:31:05PM CEST, I got a letter
>where David Greaves <david@dgreaves.com> told me that...
>  
>
>>Makefile understands the includes git.txt #includes README
>>README reformatted to asciidoc to allow inclusion in git.txt
>>
>>Signed-off-by: David Greaves <david@dgreaves.com>
>>    
>>
>
>Is it just me or this commit message is really weird? :-)
>  
>
I know, I saw it when I pushed send. Somehow a \n became a space... I
blame vi. Should be:

Makefile understands the includes
git.txt #includes README
README reformatted to asciidoc to allow inclusion in git.txt

>  
>
>>Index: README
>>===================================================================
>>--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/README  (mode:100644)
>>+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/README  (mode:100644)
>>@@ -1,9 +1,13 @@
>>+////////////////////////////////////////////////////////////////
>>+	GIT - the stupid content tracker
>>
>>
>>-
>>-	GIT - the stupid content tracker
>>+Note that this README is written in asciidoc format and is #include'd
>>+in the git.txt docs
>>
>>
>>+The rest of this README is #included in the git.txt file
>>+////////////////////////////////////////////////////////////////
>> "git" can mean anything, depending on your mood.
>>
>>  - random three-letter combination that is pronounceable, and not
>>    
>>
>
>I'd probably prefer this being much less prominent. Can it be rather at
>the bottom of the file?
>  
>
If you mean the header in the ///'s?
yes - but I wanted editors to realise it is asciidoc so kept it at the top.
It could also be toned down by using fewer ////s - but that looked a bit
odd.
(the /// /// lines act as comment block markers so asciidoc ignores the
header

Or the "git can mean anything" speech?
That's how it was originally.

>  
>
>>-the object (i.e. how it is used, and how it can refer to other objects).
>>-There are currently three different object types: "blob", "tree" and
>>-"commit".
>>+the object (ie how it is used, and how it can refer to other objects).
>>+There are currently four different object types: "blob", "tree",
>>+"commit" and "tag".
>>    
>>
>
>You're reintroducing the "typos" fixed before, apparently.
>  
>
I didn't notice the i.e. vs ie - I'm not that bothered ;)

>  
>
>> A "blob" object cannot refer to any other object, and is, like the tag
>> implies, a pure storage object containing some user data.  It is used to
>>@@ -48,7 +50,7 @@
>> directory structure. In addition, a tree object can refer to other tree
>> objects, thus creating a directory hierarchy.
>>
>>-Finally, a "commit" object ties such directory hierarchies together into
>>+A "commit" object ties such directory hierarchies together into
>> a DAG of revisions - each "commit" is associated with exactly one tree
>> (the directory hierarchy at the time of the commit). In addition, a
>> "commit" refers to one or more "parent" commit objects that describe the
>>@@ -62,12 +64,17 @@
>> just going to confuse people.  So aim for the notion of "one root object
>> per project", even if git itself does not enforce that.
>>
>>+A "tag" object symbolically identifies and can be used to sign other
>>+objects. It contains the identifier and type of another object, a
>>+symbolic name (of course!) and, optionally, a signature.
>>+
>>    
>>
>
>I think those changes should be either sent as a separate patch or noted
>as being done in the commit message.
>  
>
makes sense.
I'd rather note them in the message if that's OK

>  
>
>>@@ -245,216 +274,209 @@
>>
>>
>>
>>-	The Workflow
>>-
>>-
>>+The Workflow
>>+------------
>>    
>>
>
>
>Cannot at least the newlines be preserved?
>  
>
Yes - I must have been in an anti-whitespace mood.

Will see to this in the am...

David

--