最近Linux6.2出来了
增加了很多新的东西，有看点的是，Linux确实要可以在Apple M1上面运行了，这应该是一个很大的新闻，如果有这么稳定的硬件支持，那对于Linux来说相当于又打下了一大片的江山。
其中关于Linux6.2的特性罗列如下
Nouveau 中早期的 NVIDIA RTX 30/Ampere GPU 支持
更新了 Zstd 压缩代码
其他 Btrfs 性能增强
Squashfs 文件系统的新挂载选项
支持 Wi-Fi 7 和 800Gbps 网络的基础工作
在 exFAT 驱动程序中更快地创建文件/文件夹
RISC-V 对持久性内存设备的支持
英特尔 IFS 驱动程序现已稳定
Intel Alder Lake N/Raptor Lake P 适度节能
USB 4 连接唤醒/断开支持
支持 ChromeOS 人体存在传感器 (HPS)
Raspberry Pi 4K @ 60Hz 显示支持
6.2结束后，也代表着6.3开始了，在6.3版本的合并中，Linus发针对一次提交发飙了，发飙的原因是因为有人提交代码竟然没有好好写commit
关于如何写好一个commit，之前有文章
如下链接：
https://lore.kernel.org/lkml/CAHk-=wgw++ccN-Pd1npZsBSDD3z6EGUSKsWuAEh5YC-TmfJAug@mail.gmail.com/
提交者是这样写的：
大意是说
——Linus，请把这些更新用在Linux v6.3-rc1上，涉及一些什么什么的特性，有一些围绕着虚拟子系统的其他补丁，但是这些补丁已经被其他人reviewed了。
看Linus是如何回复的：
Linus说，我不得不再强调一次，如果你不能清楚的说明一个提交的原因，那么这次提交就显得很粗暴。
之后提交者回复如下
之后，Linus还详细的解释了自己的观点
所以说，真正的大佬是超级耐心并且讲道理的，如果没有Linus，不吹，Linus被取代迟早的事。
-
> >I
've said this before, and apparently I need to say this again: if you
-
> >cannot be bothered to explain *WHY* a merge exists, then that merge is
-
> >buggy garbage by definition.
-
>
-
> Okay, understood. This was a merge of the fixes for v6.2. I'll explain that more clearly in the log from now on. :)
-
-
So I really want people to document their merges, not just so that I
-
(and others) can see
"oh, that's why it exists at all", but also
-
because I want to
make people think about their merges more in
-
general.
-
-
For example, one reason why people do these kinds of merges is because
-
they are starting to do some
new development
for the next release, and
-
that
new development then depends on fixes or infrastructure that they
-
had in another branch (like a
"for-linus" branch in
case of fixes).
-
-
So then they - mindlessly - just do a
"git merge that-branch" and the
-
end result looks very much like what you sent me.
-
-
In a slightly better world, they then actually write an explanatory
-
commit message
for that merge, knowing that I ask
for them, and the
-
merge commit message ends up being exactly that kind of slightly odd
-
-
"Now I'm starting a new thing that depends on the fixes
-
I already sent upstream, so I'm merging that branch"
-
-
Which while certainly better than no explanation at all sounds a bit
-
odd, doesn
't it? Yeah, add a few details on just what you depend on
-
and why, and it gets much better, but it's all going to be a bit
-
hand-wavy about future work that you haven
't even written yet.
-
-
And *that* will them maybe make you then go "Ahh, I'm doing things wrong
".
-
-
Because the "nice git way
" to do that kind of thing is to actually
-
realize "oh, I
'm starting new work that depends on the fixes I already
-
sent upstram, so I should just make a new topic branch and start at
-
that point that I needed".
-
-
And then - once you've done all the
"new work" that depended on that
-
state, only at *THAT* point do you merge the topic branch.
-
-
And look - you have exactly the same commits: you have one (or more)
-
normal commits that implement the
new feature, and you have one merge
-
commit, but notice how much easier it is to write the explanation
for
-
the merge when you do it *after* the work.
-
-
Instead of having to waffle about
"future work depends on this feature
-
that was in another branch, so I'm merging this branch", your merge
-
commit now makes *sense*. You
're not merging some old state in order
-
to create new features, you are literally just merging the completed
-
new feature.
-
-
So *this* is one reason I want people to really think about, and
-
explain, their merges. Because it may be that having to explain it
-
makes you go "Oh, I'm doing this wrong
".
-
-
Now, in your case, I don't actually think you needed that merge for
-
any "future
new work
" at all. I think you just randomly did a merge to
-
just get the same warning fixes that you had already sent me. So in
-
this case, it smells like the merge was just entirely superfluous.
-
-
Those kinds of superfluous merges can be ok - it's just annoying to
-
have a development branch that still shows some artifact that you
-
already fixed elsewhere.
-
-
But they still need the explanation. And for that case, I want the
-
explanation partly to make it clear that you really *thought* about
-
it, and partly just so that I can see why you did it.
-
-
Because we have a very real history where people did mindless daily
-
back-merges like this "just because
" with absolutely no rhyme or
-
reason, just because they wanted to start each day with the most
-
recent base, and it really gets very ugly. The development history can
-
go from a DAG that actually visualizes the different development
-
streams nicely to a spider-net maze of inexplicable merges very
-
quickly.
-
-
Linus
转载：https://blog.csdn.net/weiqifa0/article/details/129210709
查看评论