Re: [PATCH] update README and #include in git.txt
- From
David Greaves <david@dgreaves.com>
- Date
- May 13, 2005, 22:29 UTC
- Message-ID
- <42852A44.7010806@dgreaves.com>
- In-Reply-To
- <20050513221306.GB32232@pasky.ji.cz>
Petr Baudis wrote:
Show 14 quoted lines
>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
Show 29 quoted lines
> > >>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.
Show 14 quoted lines
> > >>-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 ;)
Show 28 quoted lines
> > >> 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
Show 18 quoted lines
> > >>@@ -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