- 主题:git算不算典型的shit山项目？
hg的衰落是挺可惜的
【 在 hyperLee (醉里挑灯看剑) 的大作中提到: 】
: 是的， 对比之下， mercurial就好学多了，主要是mercurial的概念清晰啊。
: 有branch， 还有head. 非常符合管理的思路.
: 最关键的是随意切换到某个历史版本， 没有任何心里负担. 没有git reset这种坑人的操作
: ...................
--
FROM 122.234.60.*
git早期都没有git这个命令，是一堆分开的小命令，
现在的单个git命令是后来做的wrapper
单说git的机制，早期思路就是在文件系统上做的一个
有版本控制的“扩展”，简单底层粗暴，给kernel devs
用的，大概也没想到以后会流行成小白标配，会需要在
CLI层面上演变那么多。
【 在 unknownzerx (unknownzerx) 的大作中提到: 】
: 分支和commit的关系设计的不是挺好么.
: 概念是概念, 命令是命令.
: 命令确实设计的不好.
: ...................
--
FROM 122.234.60.*
操作高效和学习曲线低是两码事。
【 在 leadu (leadu) 的大作中提到: 】
: 人生物本质处理图形界面更高效
: 命令行有优点，常变参数的复杂输入效率高。
: 命令行缺点很明显，不好用，效率都低，脑子需要记一大堆没用的东西
: ...................
--
FROM 115.192.185.*
好吧，不同世界的人真的没法沟通
【 在 leadu (leadu) 的大作中提到: 】
: 没在说学习曲线。
: 不常用命令都得查参数，远不如界面上点几下效率高
: 命令行出个错且得花时间恢复
: ...................
--
FROM 115.192.185.*
好吧again，不同世界的人真的没法沟通+10086
【 在 leadu (leadu) 的大作中提到: 】
: 豆大，效率是个总体的事情，不能光说个ls的。
: 常用的，UI有些情况可能是稍微慢个半秒一秒的的，但不一定是所有情况都慢；
: 但遇到个记不清参数的，一天的ls就白省了。
: ...................
--
FROM 115.192.185.*
唉，成熟的IT环境用谁家的基础设施都有办法的。
不成熟的苦逼IT环境，只能在自己力所能及的范围内尽量省力和提效了。
从这个角度讲，你们这些企业级思维的大佬们虽然瞧不起我们喜欢CLI的陋逼，
但是，CLI对我们陋逼的场景真的是好用。泪奔。
【 在 leadu (leadu) 的大作中提到: 】
: 上面已经说过一遍了，换个角度再说一遍
: 如果是你假设的样子，会有如下：it为什么能登录修改hr和财务的机器？有人笔记本在家怎么办，第二天再来一遍？你不小心把老板的文件删了不承认怎么办？等等一系列问题
: 这个在企业it方面都是很成熟的解决方案了，多家软件供应商可以选择。这有微软的两张截图
: ...................
--
FROM 115.192.185.*
嗯，daily routine肯定是脚本化、自动化的。
但是我们光荣的新时代中国特色社会主义甲方综合信息化人员
差不多每天都要在服务器上处理各种不同的不正常问题……
有时候这种事还要占据挺长时间。但每个问题又都是个例。
那就只能手操了。
理论上可以用现代化办法来消减不正常问题的产生，但一来不值得，
投入精力大又不能变成绩效，二来我们处级业务单位也很难申请到做
信息化基础设施项目的经费支持。
这种情况下，我很难有心情按照理性职场人的标准来干活。
所以用顺心一点合自己脾气一点的技术栈能完成任务的，肯定不会去选
不顺心的、不合脾气的。
【 在 leadu (leadu) 的大作中提到: 】
: 豆大谦虚了，图书管理员是最牛的职业，没有之一
: 在无法取得统一部署的环境，确实会有各式各样的办法弥补。
: 如果我是在类似的环境，我会写个脚本或是开发一个小客户端，定时pull任务等，模拟企业it软件。
: ...................
--
修改:adoal FROM 115.192.185.*
FROM 115.192.185.*