作者头像
提交列表是一面名字组成的墙，而名字读起来很慢。每个名字旁边放一张图，"这是谁写的"就变成了一眼就能 回答的问题。Gitcito 会给它显示的每位作者配一张：图形视图的作者列、提交详情里作者和每位共同作者旁边、 撰写提交时的共同作者选择器、配置切换器，以及设置中每个配置的旁边。
图从哪里来
两个来源，按此顺序尝试：
| 来源 | 什么时候用 |
|---|---|
| Gravatar | 提交邮箱有 Gravatar 账号。通过 HTTPS 获取，依据邮箱小写形式的 SHA-256 哈希。 |
| 生成的头像 | 其余所有情况——没有 Gravatar、没有网络，或关闭了查询。在本地依据邮箱绘制，从不下载。 |
生成的头像是一只小生物，不是一个彩色方块：同一个邮箱永远产生同样的形状和同样的颜色，所以跨仓库、跨 重启，作者都还认得出来。两个不同邮箱基本不会撞在一起。它由 blobatar（MIT）绘制，完全不需要网络——一个满是没有 Gravatar 的作者的仓库，依然能在首次绘制时离线得到一整套可区分的面孔。
由于种子是提交邮箱，用两个地址提交的作者会得到两个头像。这是刻意的——它和图形视图作者列给出的是
同一个信号，而且通常正是这样发现机器账号或配置错误的 user.email。如果两个地址确实是同一个人，用
作者属性来纠正。
标题栏里的那张脸
配置名称旁边的头像，是 Gitcito 中唯一代表此刻、在这个仓库里的你的头像——所以它也是唯一会对仓库状 态作出反应的头像。有事发生时它会变脸，其余时候保持平常。
它对什么作出反应，从最糟的往下：仍处于冲突的文件；一个从未告诉 git 该怎么收场的合并、变基、 拣选或还原；分离的 HEAD——下面有未提交的工作时是惊慌，没有时只是茫然；未推送、或未从远端 取回而越积越多的提交；未提交而越积越多的更改；没人打开的贮藏抽屉；以及一个月没有任何东西 落地的仓库。
最糟的那个胜出：一个既有冲突又有四十个未推送提交的仓库摆出的是冲突那张脸。把指针悬停在头像 上，提示会准确说明是什么造成了这张脸——一张不说明缘由就变化的图是谜题，不是信号。要读的是提 示，脸只负责让你去看。
阈值故意设得很高。一个提交没推送就发愁的脸，会永远发愁下去，而长期亮着的信号就是人们学会不看 的信号。没有上游的分支保持平常而不是满足："已同步"这句话，对谁都没推送过的分支说不出口。
这是装饰，不是仪表。 真实计数在状态栏里，那才是该信的。这张脸只是一眼告诉你有事发生。
动效
标题栏的头像会自己呼吸和眨眼。到 设置 → 主题 → 图形 → 让头像动起来关掉它——表情仍然跟随仓库，只是不再动。当系统要求减少动效时， 动效也会自动跳过。
只有这一个头像会动。会动的头像必须画成活的 SVG 而不是缓存图片，一个尚可，而滚动的图形视图要画的几百 个就太浪费了。
关掉查询
设置 → 主题 → 图形 → 显示头像。
关掉意味着：
- 永不向
gravatar.com发出任何请求——不延后发送，也不缓存后重试； - 头像照旧出现，全部在本地生成。
所以这是一个隐私开关，不是"把图藏起来"。没有任何设置能彻底去掉头像。
限制
- 一次 Gravatar 查询会告诉 gravatar.com 这个邮箱被看过了。 哈希不是秘密：任何手里有候选邮箱的人 都能算出哈希再比对。如果一个仓库的作者名单是你不愿交给第三方的东西，打开它之前先关掉查询。
- 只支持 Gravatar。 你上传到 GitHub、GitLab 或 Bitbucket 的头像不会读取——那需要按作者逐个发起带 认证的托管方 API 调用，为一处装饰花的网络太多了。
- 不能覆盖。 你无法把选定的图片钉在某位作者身上，也无法更换生成风格。头像只是邮箱的函数，别无其他。
- Gravatar 照片没有表情。 如果你配置的邮箱有照片，标题栏就显示照片、不显示表情——照片没法对你做鬼 脸。如果你更想要会表达的小生物，就关掉查询。
- 表情只跟随当前仓库。 在不是仓库的标签页里没有可反应的对象，所以它保持平常。
- 一次只给一个判读。 这张脸只显示它找到的最糟的那一件事，所以一个仓库可以同时乱在好几处， 却仍然只摆出一种表情。它不是状态清单——那是状态栏和提示的活儿。
- 小就是小。 在图形视图的作者列里头像是 16px，能传达颜色和轮廓，传达不了细节。提交详情把作者画成 38px，那里才真的看得见脸。