Re: A shortcoming of the git repo format
- From
- David Lang <david.lang@digitalinsight.com>
- Date
- Apr 28, 2005, 00:46 UTC
- Message-ID
- <Pine.LNX.4.62.0504271743580.4990@qynat.qvtvafvgr.pbz>
- In-Reply-To
- <4270320D.5090708@dwheeler.com>
On Wed, 27 Apr 2005, David A. Wheeler wrote:
Show 6 quoted lines
> 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.
<<SNIP>>
Show 12 quoted lines
>> 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.
all you have to do is to make sure that convert-cache doesn't loose any data and you can always convert back (through as many steps as needed) to check signatures.
no matter what you do, if you change the thing that's being signed the signature is worthless, it doesn't matter if you change it in a flexible or a brittle way, it's different. the brittle approach actually makes it easier to go backwards as you KNOW exactly what it needs to be, there's no possiblity that a later tag was there, but being ignored (except for the signature)
Show 11 quoted lines
> 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 > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
-- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare