取消服务端，或者说所有客户端都能作为服务端，类似 DVCS 。
允许部分同步，只关心每个客户端节点需要处理的数据（比如 PC 和手机上生产的数据不一样，处理的数据也经常不一样），并允许后台自动同步，以提升响应和节约同步开销。
是不是要求完全同步才能用，根本上得看用户本人有没有强迫症不能容忍不同步，不是你能一刀切的问题。

@rekulas 你还能分得出几 P ，已经够可控了……

比如你是一个犯罪嫌疑人 A ，被警察 B 抓了，想要被害者 D 的刑事谅解书。于是 B 告诉你 D 的律师是 C ，要谈条件可以转达。
这样？

@Richardhtw 有没有可能有那么个 GE：女方跟当地食草男跑了，然后 OP 顺势搞定个首都圈樱花妹？
当然，前提是有能力搞得定（

@omL72EEc 其实国际接轨的话也就这样，比如跟东京比……

用 Java 开发 Android 的已经灭绝了么……

前几天发现这边支付宝倒是支持二码合一了，但是就没怎么推广。大部分都还是用微信。

可以考虑移除 git 的硬依赖。你提供的功能基本上各家 DVCS 都能支持或者都不支持（所以要自己实现），没有特别 git 的部分，甚至有背道而驰的（ git 向来鼓吹的依赖 pr ）。
毕竟支持 git 的服务不缺，DVCS 中立的服务从 Bitbucket 之后基本就凉了（ OSDN 那坨没统一前端的就算了），你能把基本功能都支持上你就是市场上最靓的仔。

就奇怪哪来那么自信凭你自己的决定想掏空就掏空了。
真那么容易，那么怕是马上就会被社会调教——容易掏的软柿子向来可是稀罕货。
顺便，负债么，正常操作就是掏银行之类。你觉得你耐掏的抗性更高么。

@bandian 这可不一定。Linux 的首要全局影响是极大地推广了 GNU GPL 。如果没有 Linux ，就凭 GNU Hurd 的难产劲儿，肯定不是 BSD 的对手。于是也不太可能出现成熟的 GPL+专有许可的商业模式，想闭源的直接就成专有软件了。GPL 基本就得靠 GCC 来扛把子。RMS 会继续鼓吹 free ，但是不会有人出来发明 open source ，因为 copyleft 不够流行所以没有划清界限和对抗的意义。苹果还是那个苹果；微软不会有理由 FUD ，但也不会向开源转进。某种意义更加割裂（专有软件仍然会是专有的），另一方面又天下大同（开源和自由的分歧不会被大多数人注意，直到又有人想造 LLVM ）才对。

@chuanqirenwu 声明的类型通过初值符的类型推断，不保证相同。和在函数模板的参数列表里写不带&的参数类型规则相同，占位符不会被推断为引用类型，于是声明的 m2 不是引用类型的变量。如果要保留引用，可以 auto&或 auto&&之类。
http://www.eel.is/c++draft/dcl.spec.auto#dcl.type.auto.deduct-3

1.先把词输入对。
范型(paradigm)
泛型(generics)
2.讨论泛型，C 放进来是用来嘲讽用的么。
这还是因为现在 C 有_Generic ，够当作底线了（但是 OP 一点没提）。
手工复制和旧式 C 宏连当作范型的底线都不配，因为和类型系统完全没有交互。
（原文评论区说无关是因为预处理器原因，这是错的，因为 pp phase 也是语言规范钦定的一部分，不应作为是否算是泛型实现的准则。否则 multi-stage programming 之类的就尬了。）
3.不要参考什么强类型弱类型之流只会让概念更加含混的伪劣资料来源。
所谓的强类型对立的就是“无”类型或者单一类型(unityped)。
更原则性上的错误在于这根本不属于类型检查，而是确保存在能被检查的类型的前提。
（ cf.github.com/FrankHB/pl-docs/blob/master/zh-CN/typing-vs-typechecking.md ）
4.装箱本质上和类型系统无关。
把装箱的外延缩小为几种 manifest typing 的语言的应用实例是一个常见理解偏差。
(cf.stackoverflow.com/a/69991369 ）
利用装箱实现泛型只是用了箱和被装的对象的非同一性；技术上，这里拿来装出来的是不是箱并不重要。
对象布局根本上需要通过 ABI 约定，箱不是描述 ABI 的抽象。
5.类型擦除和装箱无关。（为什么是 ed 不是 ing ？）
没有箱的类型擦除一样可以实现某种意义上的泛型。
6.vtable 不一定是虚“函数”表（就 Java 来说，一般叫虚方法表）。
虚表这里只是用来替代 RTTI ，跟装箱也无关。
7.同上，图中的字典传递跟装箱也无关。
而且跟虚表并列的应该是字典（虽然这个词太滥了），同样是用来实现某种 RTTI 替代品。
文章和目录里倒是正常了一点。
原文评论区有说 Type Erasure/Dictionary ，这个也不确切，更准确地，应该是+。两者都算不上是完整的实现技术。
但是前者是任意 manifest typing 意义上必要的，后者只是针对静态语言静态区分数据和所谓泛型函数的可选优化。
8.文章里说的 type parameter 暗示实现的说法是错的。
type parameter 本来就是 parameteric polymorphism 的核心，没 type parameter 的系统根本不会叫做泛型。
原文的评论区也指出了这一点。
要有区别，就是 typing 意义上的强度，例如类型系统是否允许支持所谓的 non-type parameter （根本地，形式上还是 type ，比如 dependent type ）。
9.文章链接的《透过 Rust 探索系统的本原：泛型》里把泛型函数从参数化类型中独立出来的做法在概念上是错的。
泛型函数的区别无非是类型参数和→这个类型构造器的交互，所以是参数化类型的一部分。
如果类型系统允许一个值同时居留于不带有→和带有→的类型（如类型擦除可以把*→*这个 kind 擦回*），那么单独考虑泛型函数差不多完全就是实现细节。
当然，考虑到带有→的 STLC （λ→）是 lambda cube 往其它类型系统（典型地，System F(λ2)）扩展的原点，基本上会涉及泛型函数的语言都不允许这样做，即便类型擦除有能力实现；所以这点很容易被一般的作者忽视掉。

@FrankHB 修正：返回非静态存储期的临时对象的引用。
和 @nightwitch 指出的来源一样，返回自动对象的引用是悬空引用。这里的自动对象是一个被声明的局部变量。
但是仔细看了下，OP 的代码中并不是这种情况。
问题出在 max(max(a, b), c)返回的是 const char*类型的右值，通过 temporary materialization conversion 初始化一个临时对象并初始化 T const&[T=const char*]类型的返回值，在 return 外临时对象被销毁，所以返回悬空引用。
注意这不涉及 C++意义上的变量。使用 g++时，中文警告[-Wreturn-local-addr]会把它叫做“临时变量”，这是技术上错的；而原文 returning reference to temporary 是对的，虽然过时（ ISO C++17 前就直接叫 temporary ，不叫 temporary object ）。
注意这里实际上用的是软链接过去的 Apple clang++，警告的选项不一样。
因为不是被声明变量，所以说 local （指的是作用域）也是技术上错的。
OP 的注释也是错的，悬空引用是=右边的部分；而被声明的变量 m2 就不是引用，因为用的是 auto 而不是 auto&。

能运行也是 UB 的一种。
但是应该强调，返回临时变量的引用不一定就 UB ，这里只有限定返回局部自动对象的引用时才是。否则，这会显著干扰一些问题的理解，例如：
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795

哪个标准说了单核了……
C 和 C++之类的单线程 sequence before 完全是严格按照抽象机语义体现“;”这样的语法构造的语义。
而 CPU 实际上不保证存在这种顺序。

尽管原则译码的指令流是（按程序序）顺序的（用 PC 或者 IP 之类的架构寄存器的值保存），发射和执行从来就不需要保证严格的顺序。
乱序执行在核心内部实现，单核自然也可以发生这种所谓的重排序。这时候完全不需要关心核之间通信的 MESI （虽然可以复用 MESI 这样的 uncore 协议，但除了凭空复杂以外没什么用）。
特别地，对现在的执行单元来说，它可见的是解码之后的结果即微指令构成的信号，而不需要是架构支持的 ISA 指令，后者甚至根本不保证是乱序程序的输入——有些指令根本不需要进入 CPU 的执行单元（如 Intel SnB 等的 xor zeroing ；尽管抽象上这仍然叫“执行”，因为指令被消费掉了，区分于不管输入死活的“运行”）。所谓重排的结果只是和这种微程序尽量相同的以 ISA 指令重新实现的描述。
根本上，重排也就是为了叙述方便，指出和指令流基准的默认序（程序序）不同的部分而已。（算上投机执行，任一分支路径跳转也能算基准之内。）然而你没理解清楚乱序的来源，那么这种方式就是无益的。