On Fri, Feb 24, 2017 at 05:39:43PM -0800, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > > > > what if they are forks of each other? (LEDE and OpenWRT, or just > > > linux-kernel and linux-kernel-stable) > > > > Once one flips, the other one needs to flip to, or can't interact with > > them. I know that's harsh, and is likely to create headaches. But in the > > long run, I think once everything has converged the resulting system is > > less insane. > > > > For that reason I _wouldn't_ recommend projects like the kernel flip the > > flag immediately. Ideally we write the code and the new versions > > permeate the community. Then somebody (per-project) decides that it's > > time for the community to start switching. > > can you 'un-flip' the flag? or if you have someone who is a developer flip > their repo (because they heard that sha1 is unsafe, and they want to be > safe), they can't contribute to the kernel. We don't want to have them loose > all their work, so how can they convert their local repo back to somthing > that's compatible? I don't think it would be too hard to write an un-flipper (it's basically just rewriting the newhash bit of history using sha1, and converting your refs back to point at the sha1s). > how would submodules work if one module flips and another (or the parent) > doesn't? That's a good question. It's possible that another exception should be carved out for referring to a gitlink via sha1 (we _could_ say "no, point to a newhash version of the submodule", but I think that creates a lot of hardship for not much gain). > OpenWRT/LEDE have their core repo, and they pull from many other (unrelated) > projects into that repo (and then have 'feeds', which is > sort-of-like-submodules to pull in other software that's maintained > completely independently) I think with submodules this should probably still work. If they are pulling in with a subtree-ish strategy, then they'd convert the incoming trees to the newhash format as part of that. > Microsoft has made lots of money with people being forced to upgrade Word > because one person got a new version and everyone else needed to upgrade to > be compatible. There's a LOT of pain during that process. Is that really the > best way to go? I think there's going to be a lot of pain regardless. Any attempt to mitigate that pain and work seamlessly across old and new versions of git is going cause _ongoing_ pain as people quietly rewrite the same content back and forth with different hashes. The viral-convergence strategy is painful once (when you're forced to upgrade), but after that just works. If you want to work on a dual-hash strategy, be my guest. I can't promise I'll be able to find horrific corner cases in it, but I certainly can't even try to do so until there is a concrete proposal. :) -Peff