如何处理从下而上的便利？

今天在BTRFS邮件列表上看到这样一段对话，事件虽小但颇有代表性。

Chris Mason向Linus提交BTRFS更新，但这些变更与Linus的代码树存在变更冲突，Chris或为了方便Linus就顺手解决这些冲突而生成一个新的分支，并在邮件列表里向Linus提醒这事：

There were some minor conflicts with Linus' current tree, so my branch is merged with Linus' tree as of this morning.

...

Linus, please pull the for-linus branch of the btrfs unstable tree:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus

Linus认为这样“便利”虽然省了些事，但可能会妨碍他的体验和判断，干脆直接回复道：

Gaah. Please don't do this. Unless it's a _really_ messy merge, I really do want to do the merge. It's fine to have an alternate pre-merged branch for me to compare against, but please do that separately.

So what I did was to just instead merge the state before your merge, and in the process I:

(a) noticed that your merge was incorrect (you had left around a unused "error:" label in btrfs_mount()), since I did use your merge as something to compare against (see above). That label had been removed in your branch by commit 0e78340f3c1f, but your merge resurrected it.

(b) saw just how horribly nasty your writeback_inodes_sb() end result was, and decided to clean up the estimation of dirty pages in order to not end up with the function call argument from hell.

Now, it's obviously totally possible that I screwed things up entirely in the process, but as mentioned elsewhere, I do feel that actually seeing the merge conflicts really does help me get a feel for what I'm merging, and what the points of conflict are.

And yes, maybe it's just me showing my insecurities again. I have various mental hangups, and liking to feel like I know roughly what is going on is one of them. Doing the merges and looking at the code that clashes makes me feel like I have some kind of awareness of how things are interacting in the development process.

对于复杂系统，那些意外的事件往往比那些计划内事件提供更多的信息，无视、拒绝这些“意外”只会令自己成为“局外”人。显然，带队伍的是不能成为局外人，更不要危及自己“awareness of how things are interacting in the development process”的能力。