From: Pavel Roskin <proski@gnu.org>
To: Petr Baudis <pasky@suse.cz>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id
Date: Wed, 21 Sep 2005 23:27:05 -0400 [thread overview]
Message-ID: <1127359625.8074.18.camel@dv> (raw)
In-Reply-To: <20050921100040.GE24902@pasky.or.cz>
Hello, Petr!
On Wed, 2005-09-21 at 12:00 +0200, Petr Baudis wrote:
> Dear diary, on Tue, Sep 20, 2005 at 04:25:20AM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > Don't ever assume object type in cg-object-id.
> >
> > If type is unknown in normalize_id(), make it empty so it's checked
> > later. Check parent ID that it's a commit.
>
> Why? In most of the cases, you have one pointless fork() more, and we
> "assume" only if it was in a parent line, and if that's not a commit,
> you've got a *serious* problem with your database. fsck should yell you
> to death, and I don't think you could even normally commit such a
> commit, so this should never happen. There's no point in wasting time
> trying to handle seriously messed up database.
I agree in this case. I actually was unsure, but I decided to play safe
after reading this comment in cg-tag:
# This is most usually the ID of the commit to tag. Tagging
# other objects than commits is possible, but rather "unusual".
As for fsck "yelling to death", when was the last time you tried that on
the cogito repository fetched by cogito? That's what I get:
[proski@dv cogito]$ git-fsck-objects
missing tree 0842d4cb3cd36675c518c241b16cf25fad0c5384
broken link from commit 2c70421be7d88fbee49986d7a5584d1f010a25de
to tree 8c365c79293c9a8a86dc6802f6230e389e876acb
broken link from commit 2c70421be7d88fbee49986d7a5584d1f010a25de
to commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4
broken link from commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c
to tree 0842d4cb3cd36675c518c241b16cf25fad0c5384
broken link from commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c
to commit ed34298a39b05e05bd333d9dac658df19e5b2dab
missing commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4
missing tree 8c365c79293c9a8a86dc6802f6230e389e876acb
missing commit c4cd9bc72a6e0ed355041d331bb4034d99738f82
broken link from commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451
to tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9
broken link from commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451
to commit c4cd9bc72a6e0ed355041d331bb4034d99738f82
missing tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9
missing commit ed34298a39b05e05bd333d9dac658df19e5b2dab
It's not like broken trees are exceedingly rare. Sure, this must be
some "better" kind of breakage, but anyway.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2005-09-22 3:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-20 2:25 [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id Pavel Roskin
2005-09-21 10:00 ` Petr Baudis
2005-09-22 3:27 ` Pavel Roskin [this message]
2005-09-22 9:46 ` Petr Baudis
2005-09-22 9:52 ` Petr Baudis
2005-09-22 15:37 ` Pavel Roskin
2005-09-22 15:50 ` Petr Baudis
2005-09-22 16:55 ` Pavel Roskin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1127359625.8074.18.camel@dv \
--to=proski@gnu.org \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).