Re: Migrating away from SHA-1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 12, 2016 at 06:03:02PM -0700, Junio C Hamano wrote:

> > So we'd probably need a "treev2" object type that gives room for an
> > algorithm byte (or we'd have to try to shove it into the mode, but since
> > old versions won't know the new algorithm anyway, I don't think it
> > solves that much...). Or you can just define for the whole tree object
> > (either implicit in its type, or in a header) that it always uses
> > algorithm X.
> 
> This will hurt the performance a lot during the transition period as
> it no longer will be possible to rely on "most of the time a fine
> grained commit changes only a small part of the tree, and we can
> cheaply avoid descending into trees that haven't changed because we
> can tell that the corresponding tree objects in the pre- and post-
> trees have the same object name" optimization.  But we cannot avoid
> it.

Yeah. I'd hope in general that there would be a single commit that does
the transition, and we'd only pay it when doing diffs across the
boundary. And even then, I think a local-only cache of aliases could
mitigate the worst of it.

> >   7. After a while, flip the config option on. Hopefully the readers
> >      from steps 1-5 have percolated to the masses by then, and it's not
> >      a horrible flag day.
> >
> > We're basically on step 0 right now. I'm sure I'm missing some
> > subtleties in there, too.
> 
> One subtlety is that 7. "not a flag day" may not be a good thing.
> 
> There has to be a section of a history that spans the transition,
> set of commits and trees that have pointers to both kinds of object
> names.  The narrower such a section of the history, the more
> pleasant to use the result of the transition would be.
> 
> Different projects that can have their own flag days at their own
> pace is a good thing, so the above observation does not invalidate
> your transition plan, though.

Good point. I do think projects would do well to have a moment where
they switch to the new format, and don't freely intermingle. We could
possibly do some magic there to help things out. For example, if we are
building on a commit that is sha-2, we automatically use more sha-2
objects to point to them. And then the "flag day" for a project is
simply that somebody pushes to "master" using sha-2, and everybody
else's git (which learned long ago to speak the new algorithm) just
picks it up.

Of course that's not exactly a flag day for projects that branch from
old history for bugfixes. But it might be close enough.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]