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

Petr Baudis wrote:

Dear diary, on Thu, May 12, 2005 at 11:31:05PM CEST, I got a letter
where David Greaves [off-list ref] told me that...
 

quoted

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

Signed-off-by: David Greaves <redacted>
   

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

quoted

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.

quoted

-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 ;)

quoted

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

quoted

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

--