On Fri, Feb 24, 2017 at 5:39 PM, David Lang <da...@lang.hm> 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'd think one of the first things we want is a way to flip *and* unflip by re-writing history ala git-filter-branch style. (So if you wanted, you could also flip all your old history). One unrelated thought I had. When an old client sees the new stuff, it will probably fail in a lot of weird ways. I wonder what we can do so that if we in the future have to switch to an even newer hash, how can we make it so that the old versions give a more clean error experience? Ideally so that it lessens the pain of transition somewhat in the future if/when it has to happen again? Thanks, Jake
