1. 你没有从公司复制源码，因此这个方向上不构成侵权
2. 如果你不去模仿公司申请了著作权和专利的外观设计、系统组成、特殊机制，那么这个方向也不构成侵权。但注意了，前提是你知道哪些地方是专利并且真的绕开了
3. 不构成侵权代表如果被起诉，你有能打赢的依据，但不代表对方不会起诉你
4. 如果你没盈利也构不成竞争，一般不管你什么，最多 HR 黑名单（

@Protocol 看来 OP 的作品确实不咋样，被你一本正经地指出来了

------

只能说，弱智吧混得不够多

OP 看到浏览器登录时 post 了它的密码明文时不得吓得几晚上睡不着……

在加密信道中传输的内容怎么算「明文」，你的系统输入框还「明文捕捉」了你的密码输入不是

@0o0O0o0O0o 你没抢到一楼真太可惜了

随手一搜： https://www.cnblogs.com/yinkw/p/redis_keys.html

在 kv db 里全文扫描是否搞错了什么？ 这样还不如 sqlite :memory: 呢

@cssk 电脑效果也不好，因为微信会一直有大量的消息提示弹窗，总不能设置 @才提醒吧

我试过在写代码有消息 4 个小时都没看到，不是我没去看，是每次划过去没看到红点就划回来了，4 小时候仔细一看卧槽怎么已读了

@iceheart c++中字符类型和整型是同一种类型：

'1'+1 => （这里的类型应该是？）

你说的不就是 kindle 嘛 :doge:

1. 绝大多数的泄密的原因都在用户身上，比如单一密码、存储不当、被钓鱼。 你想想对于访问者来说，密码用于加密文件本身还是用来防止访问文件有什么区别吗？
2. 在今天，绝大多数网站的 ACL 核心机制已经不是密码了，而是——手机短信。
3. 加密文件成本又高，还把更多服务方向给断绝了。我传网盘本来就是为了省空间，然后传上去所有文件还不能在线观看，意思是存照片视频文档这些文件的用户需求全都不管了，只管那些有保密需求的？
4. 你有没有下过一些「找了半天发现没有密码」的神秘小资源？——他们有个特点，要么谁都没密码，要么谁都有。

@zhaol 在他的 feture 合并前，应该准备好 4 个分支：1 你的 feature ，2 他的 feature ，4 有他 feature 的版本分支，4 没有他 feature 的版本分支

我们之前的实践是，有一个接受所有 feature 的分支，比如 master ，然后给每个要发布的版本建 release 分支，他先写完后合并到 master ，你写完，rebase master ，合并。此时 master 上有两个 feature （ 0-2-1 ），而 release 上还什么都没有。 像 gitlab 有 自动 cherry-pick 的功能，web 界面上点一下可以把整个 MR （比如你合并 master 那个 MR ）里的所有 commit 都 cherry-pick 到另一个分支上（ release ）。pick 完 release 看起来像是（ 0-1 ），但 1 的那些 commit 不是原始 commit ，是 cherry-pick 重新生成的。

如果 web 界面没有这个功能，就只能在本地手动 pick 一堆 commit 。不过鉴于 release 分支一般也不需要保留修改历史（ master 已经有了），所以可以把 feature 的所有 commit 都 squash 成一个 pick 给 release ，这样手动也不会很麻烦

@cyang812 rebase 后分岔点在基分支的最前端，merge 的分岔点是基分支上历史中的某个点。rebase 的历史永远是线性的，merge 会织出复杂的演化网。

rebase 目标分支和本分支不对等，你基本不可能搞错（不可能试图把 main 拼到 feature 上，只会把 feature 拼到 main ）
而 merge 就可 tm 难说了，feature merge main 和 main merge feature 观感上根本没什么区别，看起来也都很合法，但形成的历史网是不同的，出问题的时候根本没人有能力搞清楚发生了啥

其实没有「远端解决冲突」一说，所有的合并和冲突解决都是在叶子节点上或者说都在 git 的「客户端」进行的。

web 界面只是自动做了一些额外的事情而已，跟你在本地用一个 GUI git 工具是一回事。




> 当我的 feature 开发完毕后,origin/main 可能已经更新了很多个 commit(从其他 feature 合并而来),很可能存在冲突

此时你 **不应该进行任何 MERGE 尝试**。

1. 首先应该在本地切换到主分支（ dev/main/master ），拉取远程的状态。由于你不可能直接在这些分支上修改，所以这一步不会产生任何冲突，仅仅是快进
2. 切回到你的开发分支，把它 rebase 到主分支上，此时产生冲突，resolve ，重新 commit 。
3. 由于到目前为止你还是只修改过你的独占分支（就算有远程也是可以随便 push -f 的那个），所以不会对其他人产生任何影响。
4. push 你 rebase 过后的分支，开启或刷新 MR





之所以采用不断 rebase 分岔点的方式是因为，如果你不进行 rebase ，merge 操作时是一个三路合并，而三路合并是一个**既复杂又存在危险性** 的操作


(!!) 其实我本来想简单解释一下为什么三路合并会出问题，但在我搜索看了近一个小时文章后，我选择放弃解释：
https://www.waynerv.com/posts/git-merge-intro/
https://git-repo.info/zh_cn/2020/03/something-about-git-merge/
https://actake.github.io/2021/03/21/git%E5%BF%85%E7%9F%A5%E5%BF%85%E4%BC%9A-%E5%88%86%E6%94%AF%E5%90%88%E5%B9%B6%E9%82%A3%E4%BA%9B%E4%BA%8B/





(!!) 因为这已经是我至少第 4 次搜索这个问题然后仍然没有完全搞懂了


如果采用 rebase - merge FF 的方式，合并操作等同于在对方分支上把你做过的操作重放一次，心智负担和风险要小得多。只有一个麻烦，因为是重放，当你的 commit 序列一开始就与对方冲突时，这个冲突会有传递性（对方是 A ，你第一个提交把 A 改成了 B ，后面的提交全部在用 B ；发现冲突后你决定改成 C ，那么当你 rebase 重放的时候所有后面的提交都会不断发生 B 和 C 的冲突）。但这都可以通过减少 commit 修改量和 squash 改善，相比起三路合并能由（虽然存在疏忽的）正常操作产生 **无感知的** 丢修改相比，成本显然要低得多

1. find： https://www.runoob.com/linux/linux-comm-find.html
2. 把路径字符串扔进 python ， ''.join(路径.split('/')[::-1])
3. mv 原路径，新路径

三步，够方便不
我猜你想问 windows 平台。

1. 视频文件有封装格式和视频流编码格式两个概念（其实「格式」不准确，但正因为这两个概念容易混淆所以我用相似的词提醒）
2. 封装是指 mp4/avi/mkv 这样的容器格式，除了视频流外还可以封装音频流、字幕、音画同步信息等额外的东西。你的 test2.mov 和 test2-2.mp4 由于没有经过重编码所以它们的主要内容，即原来那个视频流，是完全一样的，只是采用了不同封装而已，类似一个 gz 压缩一个 zip 压缩
3. 视频流的编码指的是 mpeg1/h.264/AV1/hevc 之类的算法，更先进的算法可以实现更高的清晰度、分辨率的同时降低所需的空间大小。以前 av 画质时一个视频几百 m ，现在 1080p 一个视频还是几百 m ，这是编码方式在影响
4. 在采用同样编码方式的前提下（比如你展示的 3 个文件视频都是 x264 编码的，它们都是 h.264 视频流），能控制的参数也还有非常多。不同的采集设备和播放设备能支持的参数不同，所以有非常多级的标准来限制编码器的数十上百个参数变量。比如老旧便携播放器解码能力很弱，甚至没有并行指令集（ SIMD 之类的指令集），那视频就不能编码得太复杂，跟手游不用高精 3D 模型一个道理。
5. 那么具体到算法上是些什么差异呢： 前后帧变化估计的精确性、变化位置的搜索方式、搜索范围、压缩时寻找最佳字典的复杂度、区域片段「重要性」占整体的权重……

打个粗浅的比方，完美的编码：
「 这一帧的像素由前 20 帧的 x 到 y 位置卷积后与 10 帧后的 z 位置相乘得到，下一帧的图像人肉眼不可能看清，所以直接使用本帧 1/4 分辨率数据。」
辣鸡编码：
「这一帧有 1920*1080 个像素，但我只记了一万个位置的值，分区平摊吧，依次是 1.1,0.9,0.132,0.15768……」
显然完美编码体积就能很小同时也很精确。辣鸡编码就又占地又粗糙。但前者要得到这么准确的前后参考数据是要经过大量反复多次的搜索和迭代的，这也是编码器编码要花大量时间的原因。实际应用时，往往会在编码耗时和成品质量 /大小之间取舍一个合适的平衡

我说一句话： 它们这么牛逼你为啥用 sublime 做视频？

@vcfghtyjc
> 为啥会需要引用两次

你先再看一眼 1L ，然后看这个
https://onlinegdb.com/b4qgRG-ZS


哎，你别说以前可能还真有人认为会有需要 include 两次的地方

能让编译器「自己做这个事情」的提案叫 modules ，是一个有近 10 年历史的卫星，当然这跟 c++存在的漫长时间相比并不算什么

https://en.cppreference.com/w/cpp/compiler_support 在这里搜 modules 有惊喜

p.s. 别看这个 proposal 是 2019 年的，但其实随便一搜就能找到过去的弃案比如 https://isocpp.org/files/papers/n4214.pdf