看来学好英语真的很重要啊 :-)

@Coda 多谢，其实最主要的是有参与这样项目的想法。
@lyoe 目前后端工程师我努力扛着吧 :-)

什么小错误，需要明确说出来，很多时候不是nginx的问题，是nginx的upstream出现问题

你的地域是哪里，这个需要明确说出来的

这是一种很好的模式，商业和开源结合，这样的项目才能持久

@BOYPT hi，谢谢你的回答。

我们的理解是一样的，问题是对github怎么处理冲突和在你提交pull requests的时候会不会检查冲突以及提示你先解决冲突，另外是否会尝试给你智能merge。

在开发的流程中是要保持你说的这种模式。

针对我上面提到的例子，我已经做了实验了：
1 fast forward 明显可以提交 pull requests，也能 merge
2 not fast forward but auto merge 提交 pull requests，github 会给你 auto merge
3 not fast forward and can not merge 提交 pull requests，然后在 merge 的时候提示自行解决冲突

所以目前问题都明白了

@binux thanks，我只是想看看能不能找到非常了解pull requests机制的人，看来也应该就是这样子的。

@binux 如果一次修改了a文件，然后原来的repo变更的其实是添加了b文件，能智能给你merge吗？另外同一个文件不同地方的修改也是能智能merge的，我不知道 pull requests 能支持到什么地步？还是说必须 fork和origin一致， fast forward？

@BOYPT 强制要求fork和origin一致， fast forward 肯定是最简单的。因为没有冲突处理出现。

@binux 原理肯定是一样的，我不理解的是 fast forward 的不同状态导致合并出现各种情况。比如：是否有智能merge呢？还是要求clone的repo必须git pull以保持和origin repo一致？

@BOYPT 也就是说强制要求fork和origin一致，以便能 fast forward ？
如果一种情况，fork和origin在提交pull requests的时候是一致的（没有什么人修改），所以pull requests也是能成功的，但是在之后又有人在 origin 上面提交，也就是 not fast forward 了，那么在merge pull requests的时候就不允许了？

以上总结：在pull requests的提交方，merge方，是不是都需要fast forward才能通过，也就是fork和origin要求一致？

@shunai 像这种底层长期运行的服务，c/c++，开源界久经考验的软件优先。

postfix or qmail

我做代码托管的时候在这个问题上想了很久，其实可以通过ssh证书来确定提交者是谁，但是，git是一种“内部信任”管理体系，就是伪造这个commit没有什么意义，依赖大家自觉和信任，另外，如果我在另一个开发者环境里面提交了一个commit，确实commiter是自己，这样的情况也是有的，所以最后决定放开约束。

linode 是 vps，python 框架是应用层次，两个没有什么关系

@wwqgtxx now support git smart protocol，https write and read。
目前界面非常简陋，我正在寻找合适的前端、设计工程师合作。

我提供一个思路给你，在索引里面，定长数据查询效率要远远高于不定长数据，url是不定长数据，但是可以转变成为定长，如果散列足够随机，冲突不大的话，那么可以考虑，比如：
把url转换成为long值，hash(url) -> id
long值的范围是 2^64，说实话，我不认为你能达到产生冲突的可能性
然后做非uniq索引，在每次查询结果列表里面做遍历，在冲突小的情况下，每次基本返回一条数据。

如果你的数据量很小，允许一定误差，那就根本不考虑冲突的情况。

这其实就是hash的基本思想。

@jamiesun 这个事情来说你还是有错的，哪怕作为骑行者，我都提醒自己避让行人，这是个好习惯，不要那天遇到大货车。总之花钱免灾吧