From: "David A. Wheeler" <dwheeler@dwheeler.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: A shortcoming of the git repo format
Date: Wed, 27 Apr 2005 20:45:01 -0400 [thread overview]
Message-ID: <4270320D.5090708@dwheeler.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0504271352110.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 27 Apr 2005, H. Peter Anvin wrote:
>
>>I know that. However, is that going to be true for all versions of the
>>repository format over all time? If so, the repository format is brittle.
>
> I agree, it's brittle by design, exactly because I think it's very
> important not to allow any variations.
In the short term, not allowing any variations is probably a
good thing, it'll winnow out mistakes. Creating a format that
COULD change in the future is, however, a very good way of avoiding
getting boxed into a corner if it turns out a mistake has been made.
> HOWEVER, that's where "convert-cache" comes in. Any one particular format
> may be brittle, but if we accept that, and just say "we can upgrade by
> converting the cache", then we should be ok. IOW, we can change from one
> brittle format with 160-bit SHA1 names to _another_ brittle format with
> 256-bit SHA1 (or other) names.
There's a disadvantage to that, unfortunately: invalidating signatures.
Yes, you can get people to re-sign their stuff... assuming you can
find them & convince them to do it (ha!). More than likely,
you'll lose signatures that way. Probably not your TOP priority,
but there are advantages to being able to go back & years later
SHOW that someone really did sign something.
In the long run, I'd really like to see (at least) signed commits,
and that those signatures would "stick around" cleanly into the future.
"Breaks" can be handled other ways, but it is DEFINITELY a pain,
and an avoidable one.
--- David A. Wheeler
next prev parent reply other threads:[~2005-04-28 0:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-27 5:43 A shortcoming of the git repo format H. Peter Anvin
2005-04-27 15:00 ` C. Scott Ananian
2005-04-27 15:22 ` Linus Torvalds
2005-04-27 18:03 ` H. Peter Anvin
2005-04-27 18:32 ` Dave Jones
2005-04-27 18:47 ` H. Peter Anvin
2005-04-27 22:51 ` Jon Seymour
2005-04-27 19:15 ` Linus Torvalds
2005-04-27 19:39 ` Petr Baudis
2005-04-27 19:11 ` Linus Torvalds
2005-04-27 19:47 ` The " Brian O'Mahoney
2005-04-27 20:40 ` A shortcoming of the " H. Peter Anvin
2005-04-27 20:49 ` Tom Lord
2005-04-27 20:59 ` H. Peter Anvin
2005-04-28 0:57 ` Linus Torvalds
2005-04-28 1:34 ` Paul Jackson
2005-04-28 2:14 ` Tom Lord
2005-04-28 3:37 ` Ryan Anderson
2005-04-28 8:31 ` Morgan Schweers
2005-04-28 15:08 ` Barry Silverman
2005-04-27 20:56 ` Linus Torvalds
2005-04-28 0:45 ` David A. Wheeler [this message]
2005-04-28 0:46 ` David Lang
2005-04-27 23:50 ` Daniel Barkalow
2005-04-27 23:56 ` H. Peter Anvin
2005-04-28 1:51 ` Daniel Barkalow
2005-04-28 1:56 ` H. Peter Anvin
2005-04-28 13:39 ` David Woodhouse
2005-04-27 20:58 ` Gerhard Schrenk
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=4270320D.5090708@dwheeler.com \
--to=dwheeler@dwheeler.com \
--cc=git@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=torvalds@osdl.org \
/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).