Git 的 Diff 演算法

Lobsters Daily 上看到「When to Use Each of the Git Diff Algorithms」這篇 2020 的文章 (Lobsters 這邊常冒出一些舊文章),講 Git 的 diff 演算法。

文章裡面題到了四個演算法,看了一下 git-diff 的 manpage 也還是這四個:

--diff-algorithm={patience|minimal|histogram|myers}

另外看 manpage 時還有看到 --anchored 的用法,看起來是用來提示 Git 產生比較好懂的 diff 結果:

--anchored=<text>

Generate a diff using the "anchored diff" algorithm.

This option may be specified more than once.

If a line exists in both the source and destination, exists only once, and starts with this text, this algorithm attempts to prevent it from appearing as a deletion or addition in the output. It uses the "patience diff" algorithm internally.

回頭翻了一下自己的 config repository,看起來 2017 年年底的時候我就加了「Use histogram diff algorithm.」,然後過幾天換成「Use patience algorithm.」,就一直用到現在...

這次改用 minimal 跑一陣子看看好了...

用 AWK 寫的 Git

前幾天看到的東西,用 AWK 寫的 Git:「Aho: A Git implementation in AWK.」,Hacker News 上的討論「A Git Implementation in Awk (github.com/djanderson)」也可以翻一下。

Aho 這個名字取自 AWK 的作者之一 Alfred Aho (AWK 中的 A),然後查資料才發現他剛拿到去年 2020 的 Turing Award...

作者提到了為什麼會用 AWK 寫 Git,看起來就是個爽字 XDDD:

I've had the irrational desire to write something substantial in AWK for a while. Figured I might as well learn some Git internals while I scratch this itch.

然後他有提到他沒打算把網路相關的功能實做進去:

I don't plan to add network functionality to this (even though you totally can), so no clone or push.

是個有趣的專案,寫爽的 XD

InterNetNews (INN) 在測試 Git

在 mailing list 上看到「Test Git repository for INN」這個消息,看起來 InterNetNews 也在嘗試換到 Git 上了,目前是選擇用 GitHub,在「InterNetNews/inn」這邊。

整個從 CVS 換到 Subversion 再到現在開始進入 Git 的環境了。

沒有全部自己搞的理由也有提到,主要就是免費與方便,然後社群也已經知道 GitHub 是什麼了:

GitHub was chosen because it's (a) free (as in price), (b) widely understood and used already, and (c) easy for me to set up. I know some folks have reservations about GitHub because it's not free software, and I understand, but I don't think we're committing heavily to their platform (everyone who has a clone of the Git repository has all the important data and can move it elsewhere), and other things like GitLab are only open core anyway. Hosting everything on 100% free software (depending on the choice of free software) loses us some useful features (I plan to set up GitHub Actions for CI) and requires more resources that I don't really have to spend on it. That said, everyone is certainly welcome to mirror the Git repository elsewhere if they want.

之後會跑 CI,算是這些年軟體工程必備的工具了...

PHP 的 Git Server 被打穿,決定把整個 Git 系統搬到 GitHub 上

就如同標題說的:「Changes to Git commit workflow」,Hacker News 上的討論也可以看一下:「PHP's Git server compromised, moving to GitHub (php.net)」。

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our
own git infrastructure is an unnecessary security risk, and that we will
discontinue the git.php.net server. Instead, the repositories on GitHub,
which were previously only mirrors, will become canonical. This means that
changes should be pushed directly to GitHub rather than to git.php.net.

不知道發生什麼事情,要等事後的報告出來...

Dolt,本機開發測試用的 MySQL server

看到「Dolt is Git for Data!」這個專案,是個在本機上跑的 MySQL server,另外可以在上面的資料進行版本控制,看起來很適合本機開發測試。

首先抓下來可以看到沒幾個檔案 (這是 linux-amd64 版),也可以看到跟 Git 的關係:

$ tree
.
├── bin
│   ├── dolt
│   ├── git-dolt
│   └── git-dolt-smudge
└── LICENSES

然後用 bin/dolt sql-server -P 3307 -u root -p passw0rd 跑就可以把一個相容於 MySQL 的伺服器跑在 port 3307,然後用 mysql -h 127.0.0.1 --port 3307 -u root -p 就可以輸入密碼 passw0rd 登入進去:

$ mysql -h 127.0.0.1 --port 3307 -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.7.9-Vitess

可以從 Server version 看到專案是用了 Vitess 實做的 MySQL 界面。

另外測了一下,透過連線所做的變更 (像是 CREATE DATABASECREATE TABLE,以及 CRUD 中的 CUD) 是不會寫回磁碟裡的,嘗試了不同的設定,不管改什麼都是這樣,應該是故意設計成這樣。

在本機跑 test case 測試應該還不錯,會比 SQLite:memory: 更接近 MySQL 一些,不過在 CI 裡的話應該是可以直接把 MySQL 跑起來...

用 git-notify 提醒重要的訊息

不確定在哪邊看到的,但看起來蠻有趣的:「Communicate important updates to your team via git commit messages.」。

這隻程式定義了一個 convention,當你在 commit log 裡面有用 git-notify 標注時,有安裝 git-notify 這隻程式的人就會跳出提醒,像是這樣:

團隊整個一起套用下去的話,效果應該還不錯,不過一般商業團隊都應該有 Git 以外的管道可以通知 (像是 Slack),git-notify 的幫助就未必是不可取代,而且也比較侷限 (像是跟 designer 的溝通就未必會走 Git)。

算是看起來還蠻有趣的東西,記起來 XD

FreeBSD 要從 Subversion 換到 Git

#bsdchat 上面看到 FreeBSD 提供了 Git repository,翻了一下看起來是最近在切換,這邊有翻到慣例的 HEADS UP:「HEADS UP: FreeBSD changing from Subversion to Git this weekend」。

The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues.

大概是 2008 年先把 src tree 從 CVS 換到 Subversion 上:「FreeBSD src 部份由 CVS 轉換到 Subversion」。

然後 2012 年把 ports tree 換過去:「FreeBSD ports 將從 CVS 轉移到 Subversion 上...」。

雖然已經很久沒用 FreeBSD 了 (最近碰到最接近的系統應該是 pfSense),但還是先恭喜他們總算要切換了,兩邊的能量差太多了...

youtube-dl 的恢復與後續 GitHub 的處理模式

youtube-dl 被下架的事情後續又有不少進展了 (先前寫過「youtube-dl 被 RIAA 用 DMCA 打下來的事件」這篇),主要是 GitHub 恢復了 youtube-dl 的 Git Repository,然後丟出了一篇文章解釋過程,以及後續的作法:「Standing up for developers: youtube-dl is back」。

要注意這次的事件完全是法律戰,所以裡面發生的敘述都是各自的說法,大家可以自己解讀...

GitHub 的這篇文章是由 Abby Vollmer 發表的,從 LinkedIn 上的資料也可以看到他以前的經歷都是法律相關,現在在 GitHub 的頭銜是「Director of Platform Policy and Counsel」,而這篇的用字也可以看出來很小心。

首先 GitHub 認為下架的原因是 Section 1201:

Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.

而 GitHub 後續恢復 youtube-dl 的原因是收到 EFF 代表 youtube-dl 開發者所做的 counter notice:「2020-11-16-RIAA-reversal-effletter.pdf」。

照以往這種把事情搞超大的慣例,RIAA 應該是不會有後續的動作,所以就 youtube-dl 這件事情來說應該是差不多告一段落。

GitHub 後續針對 Section 1201 提出了兩個改善措施,一個是重新設計 Section 1201 的處理方式,另外一個是 GitHub 自己投入資金,降低 developer 的負擔。

但整件事情背後的問題主要是在 DMCA 的設計,讓濫發 takedown notice 的人很難受罰,在這點沒有改善之前,同樣的劇碼應該都還是會繼續上演。

kernel.org 推動 git push 的簽名

LWN 上看到 kernel.org 解釋並且推動 git push 的電子簽名:「Signed pushes for kernel.org」。

在「Signed git pushes」這篇裡面解釋了除了 git commit 本身的簽名外,另外 git push 的簽名也有重要性。

而在「Introducing the kernel.org git transparency log」這邊則是公開了對應的 git transparency log。

這個方法讓 kernel.org 上的 git repository 會更透明,加上 kernel.org 上的 git repository 會被很多人 mirror,在真的出問題的時候,大家手上也都有資料可以交叉比對...

維基基金會的 Git Server 從 Gerrit 換到 GitLab

這兩天受到注意的消息,維基基金會決定把 Git Server 從本來的 Gerrit 轉換到自建的 GitLab 上:「GitLab consultation」,在 Hacker News 上也有不少討論 (i.e. 戰文):「Wikimedia is moving to Gitlab (mediawiki.org)」。

先從官方的說法開始看,主要是 Gerrit 的運作方式與目前業界與社群的常用方式不同,也導致了 usability 不怎麼好,這使得社群與基金會的員工的學習成本偏高:

While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff.

另外也發現內部很多人會直接用外部的 Git 服務,了解後主要列出三個原因:

  • lower friction to create new repositories
  • easier setup and self-service of Continuous Integration configuration
  • more familiarity with pull-request style workflows

再來就是尋找與選擇的過程了,但其實市場上也沒什麼可以選的,從說明的 FAQ 部份可以看到 GitHub 與 GitLab,另外因為基金會的特性有強烈偏好 open source self-hosting 方案,基本上就是 GitLab 了...

不過如果是因為 code review 而決定換過去的話,我猜不完全是工具的問題,內部應該有不少政治上的問題,只是外面這次看不出來而已。

在 Hacker News 上的討論還蠻有趣的,有些前員工的發言點出了在 code review 時遇到的問題看起來不是這次換成 GitLab 可以解的。