依云's Blog

一次系统升级之后，我的许多 Python 程序突然开始报错：

[...]
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2762, in _get_metadata
    for line in self.get_metadata_lines(name):
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1415, in get_metadata_lines
    return yield_lines(self.get_metadata(name))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1405, in get_metadata
    value = self._get(path)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1609, in _get
    with open(path, 'rb') as stream:
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO'

WTF 滚坏了！立即回滚！

回滚完之后，我开始调查这个事件——因为 [archlinuxcn] 的这个包是我管的呀。而且我记得之前也遇到过一次类似的情况，当时没有深究。

检查一下软件包里的文件的权限：

>>> tar tvf python-telethon-1.17.4-1-any.pkg.tar.zst | grep PKG-INFO
-rw------- root/root      3659 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO
>>> tar tvf python-telethon-1.17.4-1-any.pkg.tar.zst | grep -- ----
-rw------- root/root      3659 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO
-rw------- root/root     12078 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/SOURCES.txt
-rw------- root/root         1 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/dependency_links.txt
-rw------- root/root        27 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/requires.txt
-rw------- root/root        15 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/top_level.txt

好奇怪，Telethon 这些包信息文件怎么只让 root 读了呢？

从 PyPI 上下载 Telethon 的原始 tar 归档回来看看，发现最近几个版本里，文件权限全部只有自己可以读（-rw-------），而所有者是 u0_a167/10167。开发者突然在 Android 系统上打包了呢……安装的时候，部分文件的权限被保留了下来（Arch Linux 打包时强烈反对使用 root 权限执行，因此我用 devtools 打包，解包部分自然是普通用户操作的，所有者无法被保留）。

然后我又看了一下之前的版本，哦豁，所有者成开发者的 id 了，但是有三个版本的 pyc 文件，还有好几个 pyc 文件都是 -rwxrwxrwx。大概系统上的低权限用户可以去改改，然后看谁跑 Telegram 机器人就拿谁的权限？

经过跟开发者的讨论，最终干掉了 pyc 文件，也不在 Android 上打包了。777 权限问题还待解决。不过我更在意的是，为什么会发生这种状况呢？setuptools 干嘛不修一修呢？别的工具创建的用于发布的 tar 归档会不会有类似的问题呢？

结果找了找，发现 setuptools 前年就有人报告这个问题，但是并没有解决。行吧，我打包时统一修正一下权限好了……

下一个 GitHub 生成的 tar 归档看看？咦，-rw-rw-r-- root/root，是处理过了么？啊对，git archive 生成的包是怎么样的？去试了试，原来一样的啊。看来 git 想到了这个问题并且处理了，只是 002 的 umask 有点意外。

Arch Linux 为了普通用户打出文件为 root 所有的 tar 归档使用了 fakeroot，那么 git 是怎么实现的呢？翻了翻代码，git 是自己生成 tar 文件的，写死了所有者是 root/root，但是权限位还是有专门的 umask，默认是 002。可以配置，比如git config --global tar.umask user一下，就会取当前 umask 作为 tar 归档里文件的 umask 了。

至于传统的 GNU autotools 构建系统创建的 tar 归档，我也创建了一个看了一下，并没有特殊处理，跟手动跑 tar 一样。

我一直没有使用 Vim 插件管理插件。我没数过，但是三四个实现肯定是有的。我不喜欢它们的原因，一是迁移成本，二是依赖太巨大：我在一个新环境上配置 Vim 时，我不希望必须访问 GitHub，而且是几十个 clone，这得多慢啊……而且这还意味着它需要有 git，能够联网，DNS 解析正常，等等。这些在各种奇怪的环境里都不容易实现啊。

后来，Vim 8 出来了，内建 packages 管理功能。不愧是官方出品，没有奇怪的依赖。插件来源用户随意，把文件放对位置就可以了。

然后，我又遇见了 git-subrepo，给了 submodule 以外的选择。简单来说它有点 vendoring 的感觉，把第三方仓库放自己里边了。如果目标没有安装 git-subrepo，也没有关系，所有文件都在这儿了，只是没有与第三方仓库同步的能力了而已。

而且，git-subrepo 和 git-notes 类似，它使用额外的 ref 来存储第三方仓库的数据。但与 notes 不同的是，subrepo 已经存在于第三方仓库了，所以我不必把 subrepo 的 ref 推得到处都是，还在每个地方 fetch 下来浪费空间。万一第三方仓库没了或者搬家了，关系也不大，反正我用的代码还在我的仓库里呀。

git-subrepo 是很棒的「pay as you go」设计呢。

有了这两个东西，我就可以尝试一下新的 Vim 插件管理方案了。刚好我需要安装 vim-go，所以就开始尝试啦～

于是开始安装：

cd ~/.vim
git subrepo clone git@github.com:fatih/vim-go.git pack/go/start/vim-go

Vim 8 会自动加载pack/*/start/*下的东西（它下边的目录跟原来的 ~/.vim 布局和用法一样），:packadd命令会加载pack/*/opt/*下的东西。

然后记得设置环境变量。首先是 GOPATH，这是放所有 Go 的源码和编译出来的库和二进制文件的地方。Go 1.8 开始默认 ~/go，但是也需要设置 GOPATH，不然 vim-go 不认。然后得把 $GOPATH/bin 加到 PATH 里去。

确认环境变量设置好之后，打开一个新的 Vim，执行:GoInstallBinaries命令安装依赖。如果中途有神秘失败的，可以把地址拷出来，在命令行里手动调用 go install xxx 安装。部分软件需要访问 Google 的服务器，国内用户注意自行配置一下国际互联网的访问。

安装好之后就有补全、自动格式化、自动加 imports、重命名什么的啦。具体看 vim-go 的文档吧。不过有几点我稍微调整了一下。

我使用 syntastic 来进行代码检查。它默认不启用针对 Go 的检查，需要配置一下：

let g:syntastic_go_checkers = ['go', 'golint']

syntastic 的显示效果比 :GoMetaLinter 命令使用 quickfix 窗口的要好很多哦。

另外不要使用 :GoLint 这个命令，它连非常简单的未定义变量都检查不出来。

而且 vim-go 好 chatty，连跳转到定义都要用显眼的颜色来报告一下成功了……安静真的很珍贵的说。

:GoDoc 我还不会用，因为它报错了：

vim-go: gogetdoc: couldn't get package for .../t.go: can't find package containing .../t.go^@

写 Go 的时候，特别是调试的时候，加句fmt.Printf得记得修改 import，不需要了还得再去删掉才能通过编译……Go 编译是快了，但是处理未使用变量比等待编译结束更令人心烦啊。

有了 goimports 这个命令之后，不需要在开发过程中反复手动修改导入的包列表了。它可以自动添加和删除 import。不过 vim-go 并没有提供在保存时自动调用的支持，所以我就自己动手了。

首先禁用掉它自己的自动格式化：

let g:go_fmt_autosave = 0

然后，是我自己设置的自动命令：

if !exists('#GoImports') && executable("goimports")
  augroup GoImports
    au!
    autocmd BufWrite *.go silent call s:GoImports()
  augroup END
endif

function! s:GoImports()
  let pos = getpos('.')
  let na = line('$')
  %!goimports
  if v:shell_error
    undo
  endif
  let nb = line('$')
  let pos[1] = pos[1] + nb - na
  call setpos('.', pos)
endfunction

还有待提高（比如 undo 的处理），但至少能用。

之前一直觉得 git 是很安全的，除非用户显式指定（比如 --force 啦，reset --hard 啦，checkout xxxx 啦），git 在用户会失去数据时都会停下来，让不小心的用户有机会处理被遗忘的修改。直到有一天，我们有个文件让 git 给吃了！

嗯，是「我们」，不是「我」。这是我们的代码部署服务器上出的事。这仓库不是我使用的，整个操作流程我也没有参与设计与评估。实际上我只是作为 troubleshooter 参与到这次神秘事件之中的。

要让 git 愉快地吃掉数据，只要这样就可以了：

• 提交 A 不包含文件 f
• 提交 B 包含文件 f
• 当前工作区为提交 A，并且包含一份未被 git 管理的文件 f，并且 f 被 gitignore 忽略掉了

然后做如下操作，未被管理的那份 f 就会消失不见了：

• 将工作区切换到提交 B。因为 f 被忽略，所以 git 不会报错（代码）
• 将工作区再切换回 A。因为 A 不包含 f，所以 f 被删掉了

正在吃 f 的 git：主人遗弃了的 f 就交给我好了～

要避免出现这种问题，当然是在 git 工作区会有修改的时候，不要依靠 git 来在多个版本间切换啦～btrfs 或者 zfs 的快照多好！如果文件系统不支持快照的话，那就用多个目录吧。

通常，创建 git 提交使用的是 git add、git commit 这些高层命令。这些命令有个特点：它们都需要工作区的存在，并且很可能会改变工作区里的文件。

如果没有工作区，或者工作区不能用的时候怎么办呢？比如想在服务器上的纯（旧称：祼）版本库里的钩子脚本里创建提交，在版本库被更新时自动生成点东西什么的。一个简单的解决方案是再克隆一份，然后在那边弄好了再 push 过来。但那样的话，你得区分一次 push 是不是由你的脚本自身触发的了。这当然是可行的，但是，不觉得直接操作纯版本库更有意思吗 O(∩_∩)O~

或者，如果你的工作区里有一个文件叫「test」，另一个文件叫「Test」，而你当前能使用的文件系统和/或操作系统是不区分文件名大小写的，这样可能就没有办法通过工作区做想要的改动了。

我之前也曾用 pygit2 来直接创建提交。那个还是比较基础的，还是需要工作区。这次让我向大家介绍一下我的新玩法，深入 git 底层，围观一下一个提交的诞生历程～～（其实是早就玩过了的，只是一直没有分享出来而已 >_<

首先，克隆一个版本库来玩儿。直接在已有的版本库里玩太危险了，万一不小心玩坏了就囧了（虽然也不是多大的问题，毕竟我有备份的嘛=w=

git clone --bare ~/.vim dotvim

读者想要一起玩的话，可以从网络克隆我的 vim 配置版本库，如

git clone --bare git://github.com/lilydjwg/dotvim dotvim

进去 dotvim 目录里 ls 一下，可以看到，只剩下以前在 .git 目录里会见到的文件了呢：

>>> ls
branches  config  description  HEAD  hooks  index  info  objects  packed-refs  refs

要创建的提交是在 master 分支上。我们先使用 ls-tree 命令看看这个分支上有哪些文件。ls-tree 其实是列出 tree 对象用的，加上 -r 参数就会递归地把 tree 对象里的 tree 对象给列出来，就像 -R 之于 ls 命令一样。

不过你给它提交（commit）对象也可以的啦。它会自动取这个提交所指向的 tree 对象：

git ls-tree -r master

相当于

git ls-tree -r 'master^{tree}'

嗯，分支名实际上是指向这个分支上的最后一个对象的符号引用。

我要把 vimrc 文件里的注释行全删掉。要想修改一个文件，就得先找到要修改的文件，而不像添加文件那样直接加进去就可以了。让我们把要修改的 vimrc 文件的 hash 值找出来：

old_vimrc=$(git ls-tree -r master | awk '$4 == "vimrc" { print $3 }')

当然这里是不必用 -r 的啦。写在这里方便嘛，下一次想改 plugin 目录下的东西可以直接改路径就可以了，不用担心要改其它可能会忘记的东西。

然后拿 cat-file 命令看看这个 blob 对象。cat-file 命令我用得挺多的，因为经常会想看看另一个分支、或者另一个提交里某个文件长什么样子。

git cat-file -p $old_vimrc

其实这里可以直接指定要显示的对象的，比如master:vimrc就是 master 对应的提交上的 vimrc 文件。如果使用 zsh 的话，冒号后边的路径部分也是可以补全的哦。这里为了阐述原理，就做「分解动作」了。

得到了文件内容，就可以修改了。修改完毕，使用 hash-object 命令将文件存入 git 对象数据库里。这一句命令相当于修改好文件之后再做 git add 操作。hash-object 会返回对象的 hash 值。我们得把它记下来。

new_vimrc=$(git cat-file -p $old_vimrc | sed '/^"/d' | git hash-object -w --stdin --path vimrc)

不管之前有没有，先删一下 index，也就是所谓的「staging area」。已经添加但是还未提交的目录树就存在这个文件里边了。

rm -f index

然后，创建我们需要的 index。得使用 ls-tree 命令列出所有文件的信息，然后把我们修改过的信息加到末尾，会自动覆盖之前已有的项。如果删除这个列表里的某些项的话，就相当于是删除了那些文件。如果添加原本不存在的项，就是添加文件了。

{git ls-tree -r master; echo -e "100644 blob $new_vimrc\tvimrc";} | git update-index --add --index-info

index 已经准备好了。我们把目录树写到 git 对象数据库里吧：

new_master_tree=$(git write-tree)

我们得到了一个新的 tree 对象的 hash 值。当然因为目录树是树状的，以上命令实际上会写入多个 tree 对象。我们只要有根 tree 对象的 hash 值就可以了。

该创建提交对象了：

commit=$(git commit-tree -p master -m '在没有工作区的情况下创建的提交' $new_master_tree)

提交对象创建好还不够。那只是一个提交对象而已，我们还没有更新分支的信息呢。我们把这个提交作为新的 master 分支的头：

git update-ref refs/heads/master "$commit"

大功告成！

可以使用git show和git log看看成果了哦～

当然，如果想要钩子脚本里使用的话，记得在修改前加锁哦。

参考资料。

为什么要异步？当然是因为慢了。比如 Arch 核心仓库 git 版挺大的，第一次进去时显示个 git 分支名要等好一会儿。今天在 zsh-users 列表中看到 Bart Schaefer 给出了一个使用 coprocess 的解决方案，眼前一亮，立即照葫芦画瓢给自己的 zsh 用上了。以下是整个提示符设置部分的代码：

if [[ -n $commands[git] ]]; then
  _nogit_dir=()
  for p in $nogit_dir; do
    [[ -d $p ]] && _nogit_dir+=$(realpath $p)
  done
  unset p

  typeset -g _current_branch= vcs_info_fd=
  zmodload zsh/zselect 2>/dev/null

  _vcs_update_info () {
    eval $(read -rE -u$1)
    zle -F $1
    exec {1}>&-
    zle reset-prompt
  }

  _set_current_branch () {
    cwd=$(pwd -P)
    for p in $_nogit_dir; do
      if [[ $cwd == $p* ]]; then
        return
      fi
    done

    setopt localoptions no_monitor
    coproc {
      _br=$(git branch --no-color 2>/dev/null)
      if [[ $? -eq 0 ]]; then
        _current_branch=$(echo $_br|awk '{if($1 == "*"){print "%{\x1b[33m%} (" substr($0, 3) ")"}}')
      fi
      # always gives something for reading, or _vcs_update_info won't be
      # called, fd not closed
      typeset -p _current_branch
    }
    disown %{\ _br
    exec {vcs_info_fd}<&p
    # wait 0.1 seconds before showing up to avoid unnecessary double update
    # precmd functions are called *after* prompt is expanded, and we can't call
    # zle reset-prompt outside zle, so turn to zselect
    zselect -r -t 10 $vcs_info_fd 2>/dev/null
    zle -F $vcs_info_fd _vcs_update_info
  }

  typeset -gaU precmd_functions
  precmd_functions+=_set_current_branch
  setopt PROMPT_SUBST
fi

[[ -n $ZSH_PS_HOST && $ZSH_PS_HOST != \(*\)\  ]] && ZSH_PS_HOST="($ZSH_PS_HOST) "

E=$'\x1b'
PS1="%{${E}[2m%}%h $ZSH_PS_HOST%(?..%{${E}[1;31m%}%?%{${E}[0m%} )%{${E}[32m%}%~\$_current_branch
%(!.%{${E}[0;31m%}###.%{${E}[1;34m%}>>>)%{${E}[0m%} "

比较坑的是使用chpwd_functions的话只能在目录改变时显示一次，再随便执行个什么命令分支提示就没了。又想到目录不改变的时候分支也可以变化（切换分支了嘛），所以使用precmd_functions，每次显示提示符前（单纯的重绘除外）都执行一次。另外，为了避免每次显示提示符时都明显地分为两步干扰视线，所以在那个_set_current_branch函数里等了 0.1 秒，超时才会不管分支名显示先继续了。

2014年2月24日更新：注意，直到 zsh 5.0.5（就是当前最新版本）有个 bug，在显示提示符之后、用户输入之前，上述代码会经常出现「忙等待」的情况浪费 CPU。这里有个补丁可以修复。

pygit2 是 libgit2 的 Python 绑定，而 libgit2 是一个可动态链接的 git 库，除去头文件和 pkgconfig 信息就一个 .so 文件。它是我在 The Architecture of Open Source Applications（AOSA）第二巻讲 git 的部分中看到的。git 本身遵循了传统的 Unix 哲学，提供了一系列的命令来管理源码库。这对于 shell 脚本是非常不错，可是对于嵌入到其它应用（如 IDE、Web 服务）中却不太好用。于是，我们有了 libgit2。

很遗憾的是，我并没有找到 API 文档，只有一些示例性的用法介绍，更别提教程之类。即使在 pygit2 中，使用help命令能够得到的信息也很有限。所以，我只能在 Python 这样动态语言的交互式会话时独自探索。

下面是我搜索出来的使用 pygit2 进行提交的过程：

导入需要用到的模块：

import pygit2
import time

我的 git 仓库，还有 index：

repo = pygit2.Repository('/home/lilydjwg/.vim/.git')
ind = repo.index

先看看未提交到 index 的修改（相当于git diff）

print(ind.diff())

唔，我看到就一个plugin/colorizer.vim文件修改了。把它加到 index 中（相当于git add）。如果是git rm的话就用del ind[filename]了。操作之后要调用write()方法写入更改。

ind.add('plugin/colorizer.vim')
ind.write()

写入 tree 对象，其返回值是二进制编码的 hash 值（使用binascii.b2a_hex可编码成 git 命令中使用的字符串）

oid = ind.write_tree()

作者和提交者的信息，其中最后一个参数（offset）是以分钟计的时区偏移（当然是相对于 UTC）。邮件地址很显然被打码了 :-)

author = pygit2.Signature('依云', 'a@b.c', int(time.time()), 480)

创建提交。其中HEAD是个「符号引用」（symbolic reference），而repo.head就是当前最后一个提交了，oid属性还是二进制编码的 hash 啦。这里，提交者和作者是同一人，因此我都使用刚刚创建的author对象了。这步就是git commit命令了。

repo.create_commit('HEAD', author, author, 'colorizer: solved name color conflict', oid, [repo.head.oid])

在命令行下看看结果是否正确：

>>> git cat-file -p HEAD
tree 20e8937d41b6df16da2c8c5661f9c4a8dd31b5a1
parent ab9c662ce0d1cb2deac7a9ae388ecb40d8ec5e15
author 依云 <a@b.c> 1340188028 +0800
committer 依云 <a@b.c> 1340188028 +0800

colorizer: solved name color conflict

当初看 Pro Git 时就被作者这个“核弹级选项”的称呼吓到了，因此一直没敢好奇地去尝试。核弹啊，用对了威力无穷，用错了破坏力无穷！

但是，今天，我不得不用了，因为我想把我的 Python 脚本放到 github 上去公开。由于之前没想过要公开，所以不能肯定是不是把诸如密码之类的敏感数据直接写代码里了。于是我就用 git 的 pickaxe 选项-S来找找看。这个我也是今天才学到的哦，来源是stackoverflow上的若干问题，具体记不清了。

这个选项结合git log，其功能是把提交中包含某个文本的提交找出来。比如git log --stat -S密码就把所有提交中包含“密码”二字的提交找出来了，同时--stat告诉 git 我希望看到文件列表，以确定敏感数据在哪个文件里。另外说下zsh，我设置了hist_ignore_space选项，所以当查找密码时我在命令行最开始输入个空格，这样 zsh 就不会把这条命令写到命令历史里。

找了下，还真发现了两个包含密码的文件（其中之一 base64 过，另一个直接明文。。。）。我决定把它们转移到其它目录下，所以要删除这些文件。同时我意外地发现，有些提交中我引用了之前的提交，比如“(after xxx) fix xxx”这种。重写 git 历史后这些提交的 sha1 值会改变，所以这些提交信息也要重写。最开始我想把提交 sha1 修改为重写后的值，后来发现有点麻烦，得通过提交 sha1 查询一个备份中的提交信息（如果不事先保存相关信息的话），然后再通过提交信息查询重写后的提交的 sha1 值，还不知道 filter-branch 时能不能查询历史，于是作罢。还好这个仓库中只有一个这样的提交，所以我直接修改成~n表示引用第 n 次前的提交算了。最后，整个命令出来了：

git filter-branch --tree-filter 'rm -rf files_to_remove' --msg-filter '
sed s/d101601/~8/
' --prune-empty -f HEAD --all

命令挺复杂的，所以我是调用 Vim 写好的，然后在一个 clone 出来的仓库里先试运行。先解释下各个参数：

• --tree-filter表示修改文件列表。
• --msg-filter表示修改提交信息，原提交信息从标准输入读入，新提交信息输出到标准输出。
• --prune-empty表示如果修改后的提交为空则扔掉不要。在一次试运行中我发现虽然文件被删除了，但是还剩下个空的提交，就查了下 man 文档，找到了这个选项。
• -f是忽略备份。不加这个选项第二次运行这个命令时会出错，意思是 git 上次做了备份，现在再要运行的话得处理掉上次的备份。
• --all是针对所有的分支。

试运行了几次，看到 150 多次提交逐一被重写，然后检查下，发现要删除的文件确实被删除了。于是高兴地到 github 建立新仓库，把脚本上传了。仓库名叫winterpy，因为网友 Vayn 建议我用 summerpy，而我更喜欢冬季 :-P

折腾完毕，我更加喜欢 git 了 :-)