Re: Suggestion on hashing

From: Bill Zaumen <bill.zaumen@gmail.com>
Date: Dec 7, 2011, 01:44 UTC
Message-ID: <1323222276.1705.434.camel@yos>
In-Reply-To: <CACsJy8CXkz-W3Z3pX-C-+fjLz=WahBajE2uLEG-f3gG_svEhug@mail.gmail.com>

On Tue, 2011-12-06 at 13:23 +0700, Nguyen Thai Ngoc Duy wrote:

> On Tue, Dec 6, 2011 at 1:02 PM, Bill Zaumen <bill.zaumen@gmail.com> wrote:

Show 12 quoted lines

> > If you are replacing SHA-1 as an object ID with another hash function,
> > two things to watch are submodules and alternative object databases.
> > Because of those, it is necessary to worry about the order in which
> > repositories are converted.  In the worst case for submodules, you'd
> > have to do multiple repositories at the same time, switching between
> > them depending on what you need at each point.
> 
> I know migration would be painful. But note that new repos can benefit
> stronger digest without legacy (of course until it links to an old
> repo). For submodules, I think we should extend it to become something
> similar to soft-link: git link is an SHA-1 to a text file that
> contains SHA-1 and maybe other digests of the submodule's tip.

Repositories would need to store a table mapping old SHA-1 values to the new ones (for commits). There's nothing in a repository to reliably indicate that it is being used as a submodule, and the choice of submodules can vary from commit to commit, making it difficult to control the order in which objects have their hashes updated. In some corner cases, you could have two branches in each of two repositories with different choices as to which is a submodule of which, although I'd be surprised if anyone actually did that.

Aside from that, in some corporate environments, the IT departments want to determine the release schedule for applications, and would take a dim view of changes that could not be tested first without being widely deployed. You could end up making Git unacceptable for those departments if you do not maintain backwards compatibility with existing repositories.