From: David Greaves Date: Fri, 13 May 2005 22:29:24 GMT Subject: Re: [PATCH] update README and #include in git.txt Message-ID: <42852A44.7010806@dgreaves.com> In-Reply-To: <20050513221306.GB32232@pasky.ji.cz> Petr Baudis wrote: >Dear diary, on Thu, May 12, 2005 at 11:31:05PM CEST, I got a letter >where David Greaves 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 >> >> > >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 --