Git发布2.21版本,为时间戳增加人类可读格式

Git官方在2月24日发布了Git 2.21,为时间戳增加了人类可读的日期格式,在不同情况Git会输出不同格式的日期,而GitHub官方博客除了解释Git 2.21更新变化外,还顺带一并说明了前一版本Git 2.20更新带来的影响。

在Git 2.21中,开发者现在可以使用“—date=human”选项,让Git输出人类可读的日期格式。 Git日志会显示每个提交的创建日期,以作为输出的一部分,当开发者没有调整,则时间戳将会以Tue Feb 12 09:00:33 2019 -0800这样的—date=default默认格式显示。

Github平台工程师Taylor Blau提到,虽然这样的格式很精确详细,但是随着时间经过,细节便会变得不太重要,开发者可能只关心相对时间。因此Git也提供了—date=relative这样的选项,系统可以显示6天前这样的相对时间格式,但是相对时间格式提供的信息,在部分情况又不够精准,所以现在官方进一步综合了两种格式,提供—date=human选项,这种格式比—date=relative更精确,但又比—date=default更容易阅读,会依照不同规则显示三分钟前、2月14日星期四20:46,或是2011年2月21日等不同格式的时间。

而—date=human还能设置为自动模式—date=auto:human,这样的设计是为了考量用户在撰写脚本的时候,需要在人类与机器可读时间格式间互相切换,因此当要输出到分页器的时候,时间会以—date=human格式输出,而在非分页器输出时,则会以默认格式显示。用户也可以在不同的时间格式使用auto属性,像是—date=auto:relative,在不同的时间格式与默认格式中切换。

另外,Taylor Blau也顺带提到了前一个版本Git 2.20,改善了常见的大小写不分路径冲突的问题。过去开发者在复制(Clone)存储库后,开发者会常获得部分文件已经被修改的Git状态通知,并且出现错误。 Taylor Blau表示,会导致这样错误,原因通常是因为存储库中包含了无法在文件系统中显示的树,像是在路径中同时存在file以及FILE字词,但是用户系统中的文件系统不区分大小写,因此Git可能无法正确的将文件放入工作目录中,而且因为Git不会在复制期间侦测大小写,因此可能也会发生把多个文件当作同一个文件的情况。

由于发生这种情况因系统而异,Taylor Blau提到,除了英文本大小写转换外,特定语言、非打印字符或是Unicode范式也都有相同的现象发生。在Git 2.20中,Git复制已经可以在初始将文件放入工作目录的阶段,进行侦测并回应冲突,不过,Git系统并无法帮助开发者解决问题,只能发出警告,因此Taylor Blau建议,不要在多平台项目中使用仅有大小写不同的文件名称。