Validation of a commit object?

Validation of a commit object?

[Shawn Pearce]

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.

-- 
Shawn.

Re: Validation of a commit object?

[Alex Riesen]

On 8/14/06, Shawn Pearce <spearce@spearce.org> wrote:
> 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.

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.

Re: Validation of a commit object?

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

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

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.