Re: A shortcoming of the git repo format
- From
David A. Wheeler <dwheeler@dwheeler.com>
- Date
- Apr 28, 2005, 00:45 UTC
- Message-ID
- <4270320D.5090708@dwheeler.com>
- In-Reply-To
- <Pine.LNX.4.58.0504271352110.18901@ppc970.osdl.org>
Linus Torvalds wrote:
Show 8 quoted lines
> > 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.
Show 5 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.
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