A shortcoming of the git repo format

Most of git's files are starting to converge toward an RFC822-like 
header with (tag, data) and a free-form section.  This is a good thing. 
  However, there is one problem with this, and that is that without 
knowing every possible tag, a program reading the git repository cannot 
safely tell what is a link to another git object and what is not.  When 
I did my repository conversion tools, I simply assumed any string of 20 
hexadecimal digits was a pointer, but this is probably a bad idea in the 
long run.

Additionally, there is the question of the handling of strings that may contain \n or even \0 (which may be necessary for some applications).

One solution to all of this would be to define a quoting standard for strings, and simply require that all free-format strings (like the author fields) or at least strings that match [0-9a-f]{20}, are always quoted.

I propose the following:

- Any string containing control characters or \ must be quoted;
- \xXX produces control characters; other characters following \ are 
verbatim.

Thus,

link 0123456789abcdef0123

... is a link to an object, whereas ...

string \0123456789abcdef0123

... is a string.

string1 This string begins with a space string2 This string has an embedded newline ("\x0a")

... are both valid strings; the first contains a leading space and the second an embedded newline.

I'll implement this and integrate it tomorrow.

	-hpa