Validation of a commit object?

In looking at fsck-objects.c the only thing it tries to validate about a commit is:

 - the commit has a tree ("tree NNNNNN\n");
 - the commit maybe has parent(s) ("parent NNNNN\n");
 - the commit has "author ".

That's it.

Its OK for an author line to be completely corrupt and have no timestamp, no name, no timezone. Or to have a timestamp such as "bobthetalkingdog".

Its OK for a committer line to just plain not exist or to be equally corrupt.

I'm thinking that can't be right. Shouldn't fsck-objects be doing better checking on commits?

The reason I ask is I'm working on my (bastard) fast-import program for Jon's Mozilla CVS -> GIT conversion effort and I'm taking the author and committer lines blind from the Python code. If the Python code gives me a bad line its going to go into the pack that way, with that possibly resulting in a totally corrupt repository. I hoped to apply the same verification that fsck-objects applies but apparently it doesn't do anything. :-)

I'm willing to write some better validation in fsck-objects.c and submit the patch if folks think we should do stronger checks in there.

On 8/14/06, Shawn Pearce <spearce@spearce.org> wrote:

Apart from timestamp, which is used in merge base and rev-list calculations, it does not look like "a totally corrupt repository". "Slightly corrupt", perhaps - you still can work with it, so long the blobs, commits and trees make sense.

Shawn Pearce <spearce@spearce.org> writes:

Historical repositories (e.g. very early days of git, linux-2.6 just after 2.6.12-rc2, and sparse) used to have commit objects that recorded committer dates in RFC2822 format not the current unixtime format. I think all of them have been converted later, but not warning or checking these fields may be related to it.

In general stricter check is always preferred. I just wanted to mention the older repositories as something we might want to keep in mind.