Merge branch 'LCTT:master' into master

published/20231110 Stunning New Steam Deck OLED Unveiled.md

@@ -0,0 +1,100 @@
+[#]: subject: "Stunning New Steam Deck OLED Unveiled!"
+[#]: via: "https://news.itsfoss.com/steam-deck-oled/"
+[#]: author: "Sourav Rudra https://news.itsfoss.com/author/sourav/"
+[#]: collector: "lujun9972/lctt-scripts-1693450080"
+[#]: translator: "ChatGPT"
+[#]: reviewer: "wxy"
+[#]: publisher: "wxy"
+[#]: url: "https://linux.cn/article-16368-1.html"
+
+震撼登场！全新的 Steam Deck OLED 公开亮相！
+======
+
+![][0]
+
+> 一款全新的、拥有更好显示效果以及卓越规格的 Steam Deck。
+
+随着假期临近，Valve 带给我们可能让这个季节更加欢乐的一些新鲜事。
+
+他们近期的一次公告中，揭露了具备多项令人兴奋升级的**全新 Steam Deck 变体**。
+
+快来一起深入了解一下吧。
+
+### 🆕 Steam Deck OLED：有哪些新特点？
+
+此款 Steam Deck 变体，如名所示，配备了**全新的 90Hz、7.4 英寸 HDR OLED 显示屏**，支持达到**高达 1,000 尼特的 HDR 峰值亮度**以及**600 尼特的 SDR 亮度**。
+
+相较于现有的配备了 LCD 的型号， OLED 显示屏能够**为玩家呈现更为深邃的黑色和更加明亮的色彩**。
+
+然而，超凡的显示屏**并非新款 Steam Deck 唯一的亮点**，它的处理器也实现了升级，**更高效的 6 纳米 AMD “Sephiroth” APU**如今负责所有板上的处理任务。
+
+作为上述特性的补充，Steam Deck OLED 还配备有**更大容量的 50Whr 电池**，能够带给你持久的电池续航。
+
+在连接性方面，它提供了**Wi-Fi 6** 和 **Bluetooth 5.3**，实现了**更优质的下载体验**。
+
+> 📋 配有一根 2.5m 的电缆的 45W USB Type-C PD3.0 电源供应器，以便为电池充电。
+
+对于**控制器也有所改进**，优化了模拟摇杆的顶部材料和形状，实现了更佳的粘性和防尘性，肩部按钮的反应更敏捷，并提供优越的触感反馈等等。
+
+**操作系统仍然是 LCD 版本上的 Steam OS 3**，但是，如果你想尝试些不同的东西，不妨试试 [Bazzite][1]。
+
+#### 🛠️ 主要规格
+
+如果你想了解，新推出的 Steam Deck OLED 其实力如何？这里有详细的配置：
+
+  * **APU：** 6 纳米 AMD “Sephiroth”
+  * **CPU：** 4 核，[Zen 2][3]，主频 2.4–3.5 GHz
+  * **GPU：** 8x [RDNA 2][4] 处理单元，主频 1.6 GHz
+  * **RAM：** 16 GB LPDDR5
+  * **存储：** 512 GB 或 1 TB 的 NVMe SSD
+  * **操作系统：** [SteamOS][5] 3（基于 Arch）
+  * **重量：** 669 克
+
+**但是，等等，还有更多！**
+
+Valve 也推出了**特别的限量版 Steam Deck OLED** ，它具有所有相同的技术规格和 1 TB 的存储，**透明壳体以及烟雾般透明的外观色彩**。一起来看看吧👇
+
+![][6]
+
+它看起来真的很酷。我非常喜欢许多制造商现在的做法，通过透明的外壳来展示设备本身。也许，这是一个很好的趋势。
+
+Valve 表明，这款设备只在美国和加拿大有**数量有限的供应**。
+
+这个量产策略之所以限量，是因为他们想**尝试**了解是否有大量的对此类产品的需求，他们计划在未来尝试更多的颜色方案。
+
+### 🛒 在哪儿购买呢？
+
+**起价为 549 美元**，你可以在 11 月 16 日之后在 [Steam Store][7] 采购 Steam Deck OLED。
+
+但请注意，并非所有 Steam 运营的区域都有销售。
+
+> **[Steam Deck OLED][7]**
+
+如果你在想；**原有的 Steam Deck LCD 版本会怎么样？**
+
+嗯，这些机型依然会有供应，并会定期更新。
+
+💬 在即将到来的假期季节，你会想要购买一台吗？请在下方让我知道你的想法！
+
+
+--------------------------------------------------------------------------------
+
+via: https://news.itsfoss.com/steam-deck-oled/
+
+作者：[Sourav Rudra][a]
+选题：[lujun9972][b]
+译者：[译者ID](https://github.com/译者ID)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]: https://news.itsfoss.com/author/sourav/
+[b]: https://github.com/lujun9972
+[1]: https://news.itsfoss.com/bazzite/
+[2]: https://news.itsfoss.com/content/images/size/w256h256/2022/08/android-chrome-192x192.png
+[3]: https://en.wikipedia.org/wiki/Zen_2
+[4]: https://en.wikipedia.org/wiki/RDNA_2
+[5]: https://itsfoss.com/steamos/
+[6]: https://news.itsfoss.com/content/images/2023/11/Steam_Deck_OLED_LE.png
+[7]: https://store.steampowered.com/steamdeck
+[0]: https://img.linux.net.cn/data/attachment/album/202311/11/144604h3w4wf53jg4ftw7w.jpg

sources/tech/20231110 How git cherry-pick and revert use 3-way merge.md

@@ -0,0 +1,302 @@
+[#]: subject: "How git cherry-pick and revert use 3-way merge"
+[#]: via: "https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/"
+[#]: author: "Julia Evans https://jvns.ca/"
+[#]: collector: "lujun9972/lctt-scripts-1693450080"
+[#]: translator: " "
+[#]: reviewer: " "
+[#]: publisher: " "
+[#]: url: " "
+
+How git cherry-pick and revert use 3-way merge
+======
+
+Hello! I was trying to explain to someone how `git cherry-pick` works the other day, and I found myself getting confused.
+
+What went wrong was: I thought that `git cherry-pick` was basically applying a patch, but when I tried to actually do it that way, it didn’t work!
+
+Let’s talk about what I thought `cherry-pick` did (applying a patch), why that’s not quite true, and what it actually does instead (a “3-way merge”).
+
+This post is extremely in the weeds and you definitely don’t need to understand this stuff to use git effectively. But if you (like me) are curious about git’s internals, let’s talk about it!
+
+### cherry-pick isn’t applying a patch
+
+The way I previously understood `git cherry-pick COMMIT_ID` is:
+
+  * calculate the diff for `COMMIT_ID`, like `git show COMMIT_ID --patch > out.patch`
+  * Apply the patch to the current branch, like `git apply out.patch`
+
+
+
+Before we get into this – I want to be clear that this model is mostly right, and if that’s your mental model that’s fine. But it’s wrong in some subtle ways and I think that’s kind of interesting, so let’s see how it works.
+
+If I try to do the “calculate the diff and apply the patch” thing in a case where there’s a merge conflict, here’s what happens:
+
+```
+
+    $ git show 10e96e46 --patch > out.patch
+    $ git apply out.patch
+    error: patch failed: content/post/2023-07-28-why-is-dns-still-hard-to-learn-.markdown:17
+    error: content/post/2023-07-28-why-is-dns-still-hard-to-learn-.markdown: patch does not apply
+
+```
+
+This just fails – it doesn’t give me any way to resolve the conflict or figure out how to solve the problem.
+
+This is quite different from what actually happens when run `git cherry-pick`, which is that I get a merge conflict:
+
+```
+
+    $ git cherry-pick 10e96e46
+    error: could not apply 10e96e46... wip
+    hint: After resolving the conflicts, mark them with
+    hint: "git add/rm <pathspec>", then run
+    hint: "git cherry-pick --continue".
+
+```
+
+So it seems like the “git is applying a patch” model isn’t quite right. But the error message literally does say “could not **apply** 10e96e46”, so it’s not quite _wrong_ either. What’s going on?
+
+### so what is cherry-pick doing?
+
+I went digging through git’s source code to see how `cherry-pick` works, and ended up at [this line of code][1]:
+
+```
+
+    res = do_recursive_merge(r, base, next, base_label, next_label, &head, &msgbuf, opts);
+
+```
+
+So a cherry-pick is a… merge? What? How? What is it even merging? And how does merging even work in the first place?
+
+I realized that I didn’t really know how git’s merge worked, so I googled it and found out that git does a thing called “3-way merge”. What’s that?
+
+### how git merges files: the 3-way merge
+
+Let’s say I want to merge these 2 files. We’ll call them `v1.py` and `v2.py`.
+
+```
+
+    def greet():
+        greeting = "hello"
+        name = "julia"
+        return greeting + " " + name
+
+    def say_hello():
+        greeting = "hello"
+        name = "aanya"
+        return greeting + " " + name
+
+```
+
+There are two lines that differ: we have
+
+  * `def greet()` and `def say_hello`
+  * `name = "aanya"` and `name = "julia"`
+
+
+
+How do we know what to pick? It seems impossible!
+
+But what if I told you that the original function was this (`base.py`)?
+
+```
+
+    def say_hello():
+        greeting = "hello"
+        name = "julia"
+        return greeting + " " + name
+
+```
+
+Suddenly it seems a lot clearer! `v1` changed the function’s name to `greet` and `v2` set `name = "aanya"`. So to merge, we should make both those changes:
+
+```
+
+    def greet():
+        greeting = "hello"
+        name = "aanya"
+        return greeting + " " + name
+
+```
+
+We can ask git to do this merge with `git merge-file`, and it gives us exactly the result we expected: it picks `def greet()` and `name = "aanya"`.
+
+```
+
+    $ git merge-file v1.py base.py v2.py -p
+    def greet():
+        greeting = "hello"
+        name = "aanya"
+        return greeting + " " + name⏎
+
+```
+
+This way of merging where you merge 2 files + their original version is called a **3-way merge**.
+
+If you want to try it out yourself in a browser, I made a little playground at [jvns.ca/3-way-merge/][2]. I made it very quickly so it’s not mobile friendly.
+
+### git merges changes, not files
+
+The way I think about the 3-way merge is – git merges **changes** , not files. We have an original file and 2 possible changes to it, and git tries to combine both of those changes in a reasonable way. Sometimes it can’t (for example if both changes change the same line), and then you get a merge conflict.
+
+Git can also merge more than 2 possible changes: you can have an original file and 8 possible changes, and it can try to reconcile all of them. That’s called an octopus merge but I don’t know much more than that, I’ve never done one.
+
+### how git uses 3-way merge to apply a patch
+
+Now let’s get a little weird! When we talk about git “applying a patch” (as you do in a `rebase` or `revert` or `cherry-pick`), it’s not actually creating a patch file and applying it. Instead, it’s doing a 3-way merge.
+
+Here’s how applying commit `X` as a patch to your current commit corresponds to this `v1`, `v2`, and `base` setup from before:
+
+  1. The version of the file **in your current commit** is `v1`.
+  2. The version of the file **before commit X** is `base`
+  3. The version of the file **in commit X**. Call that `v2`
+  4. Run `git merge-file v1 base v2` to combine them (technically git does not actually run `git merge-file`, it runs a C function that does it)
+
+
+
+Together, you can think of `base` and `v2` as being the “patch”: the diff between them is the change that you want to apply to `v1`.
+
+### how cherry-pick works
+
+Let’s say we have this commit graph, and we want to cherry-pick `Y` on to `main`:
+
+```
+
+    A - B (main)
+     \
+      \
+       X - Y - Z
+
+```
+
+How do we turn that into a 3-way merge? Here’s how it translates into our `v1`, `v2` and `base` from earlier:
+
+  * `B` is v1
+  * `X` is the base, `Y` is v2
+
+
+
+So together `X` and `Y` are the “patch”.
+
+And `git rebase` is just like `git cherry-pick`, but repeated a bunch of times.
+
+### how revert works
+
+Now let’s say we want to run `git revert Y` on this commit graph
+
+```
+
+    X - Y - Z - A - B
+
+```
+
+  * `B` is v1
+  * `Y` is the base, `X` is v2
+
+
+
+This is exactly like a cherry-pick, but with `X` and `Y` reversed. We have to flip them because we want to apply a “reverse patch”.
+
+Revert and cherry-pick are so closely related in git that they’re actually implemented in the same file: [revert.c][3].
+
+### this “3-way patch” is a really cool trick
+
+This trick of using a 3-way merge to apply a commit as a patch seems really clever and cool and I’m surprised that I’d never heard of it before! I don’t know of a name for it, but I kind of want to call it a “3-way patch”.
+
+The idea is that with a 3-way patch, you specify the patch as 2 files: the file before the patch and after (`base` and `v2` in our language in this post).
+
+So there are 3 files involved: 1 for the original and 2 for the patch.
+
+The point is that the 3-way patch is a much better way to patch than a normal patch, because you have a lot more context for merging when you have both full files.
+
+Here’s more or less what a normal patch for our example looks like:
+
+```
+
+    @@ -1,1 +1,1 @@:
+    - def greet():
+    + def say_hello():
+        greeting = "hello"
+
+```
+
+and a 3-way patch. This “3-way patch” is not a real file format, it’s just something I made up.
+
+```
+
+    BEFORE: (the full file)
+    def greet():
+        greeting = "hello"
+        name = "julia"
+        return greeting + " " + name
+    AFTER: (the full file)
+    def say_hello():
+        greeting = "hello"
+        name = "julia"
+        return greeting + " " + name
+
+```
+
+### “Building Git” talks about this
+
+The book [Building Git][4] by James Coglan is the only place I could find other than the git source code explaining how `git cherry-pick` actually uses 3-way merge under the hood (I thought Pro Git might talk about it, but it didn’t seem to as far as I could tell).
+
+I actually went to buy it and it turned out that I’d already bought it in 2019 so it was a good reference to have here :)
+
+### merging is actually much more complicated than this
+
+There’s more to merging in git than the 3-way merge – there’s something called a “recursive merge” that I don’t understand, and there are a bunch of details about how to deal with handling file deletions and moves, and there are also multiple merge algorithms.
+
+My best idea for where to learn more about this stuff is Building Git, though I haven’t read the whole thing.
+
+### so what does `git apply` do?
+
+I also went looking through git’s source to find out what `git apply` does, and it seems to (unsurprisingly) be in `apply.c`. That code parses a patch file, and then hunts through the target file to figure out where to apply it. The core logic seems to be [around here][5]: I think the idea is to start at the line number that the patch suggested and then hunt forwards and backwards from there to try to find it:
+
+```
+
+     /*
+         * There's probably some smart way to do this, but I'll leave
+         * that to the smart and beautiful people. I'm simple and stupid.
+         */
+        backwards = current;
+        backwards_lno = line;
+        forwards = current;
+        forwards_lno = line;
+        current_lno = line;
+      for (i = 0; ; i++) {
+         ...
+
+```
+
+That all seems pretty intuitive and about what I’d naively expect.
+
+### that’s all!
+
+I was pretty surprised to learn that I didn’t actually understand the core way that git applies patches internally – it was really cool to learn about!
+
+I have [lots of issues][6] with git’s UI but I think this particular thing is not one of them. The 3-way merge seems like a nice unified way to solve a bunch of different problems, it’s pretty intuitive for people (the idea of “applying a patch” is one that a lot of programmers are used to thinking about, and the fact that it’s implemented as a 3-way merge under the hood is an implementation detail that nobody actually ever needs to think about).
+
+Also a very quick plug: I’m working on writing a [zine][7] about git, if you’re interested in getting an email when it comes out you can sign up to my [very infrequent announcements mailing list][8].
+
+--------------------------------------------------------------------------------
+
+via: https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/
+
+作者：[Julia Evans][a]
+选题：[lujun9972][b]
+译者：[译者ID](https://github.com/译者ID)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]: https://jvns.ca/
+[b]: https://github.com/lujun9972
+[1]: https://github.com/git/git/blob/dadef801b365989099a9929e995589e455c51fed/sequencer.c#L2353-L2358
+[2]: https://jvns.ca/3-way-merge/
+[3]: https://github.com/git/git/blob/dadef801b365989099a9929e995589e455c51fed/builtin/revert.c
+[4]: https://shop.jcoglan.com/building-git/
+[5]: https://github.com/git/git/blob/dadef801b365989099a9929e995589e455c51fed/apply.c#L2684
+[6]: https://jvns.ca/blog/2023/11/01/confusing-git-terminology/
+[7]: https://wizardzines.com
+[8]: https://wizardzines.com/zine-announcements/