# Validation of a commit object? 3 messages from 2006-08-14 to 2006-08-14. Participants: Shawn Pearce, Alex Riesen, Junio C Hamano. Thread: https://gitlist.dev/t/5240 ## Shawn Pearce, 2006-08-14 06:28 Subject: Validation of a commit object? Message-ID: <20060814062830.GF18667@spearce.org> URL: https://gitlist.dev/e/20060814062830.GF18667%40spearce.org ``` 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. ``` ## Alex Riesen, 2006-08-14 08:39 Subject: Re: Validation of a commit object? Message-ID: <81b0412b0608140139l2937669arbef1e303d1c739bb@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0608140139l2937669arbef1e303d1c739bb%40mail.gmail.com In-Reply-To: <20060814062830.GF18667@spearce.org> ``` On 8/14/06, Shawn Pearce 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. ``` ## Junio C Hamano, 2006-08-14 21:32 Subject: Re: Validation of a commit object? Message-ID: <7vr6zjdmw9.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr6zjdmw9.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060814062830.GF18667@spearce.org> ``` Shawn Pearce 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. ```