清出一個乾淨的 Git Repository

自動化機制中,要確保可以拿到最新的 Git Repository 最保險的方法是 rm -rf 掉再重新 clone 一份,但對於稍微大一點的 repository 速度就太慢了,所以得想辦法保留 repository 加快速度。

目標是想要處理 submodule 的變更,並且仍然可以處理 force push 時的災難,避免需要人工介入... 這在建各種自動化機制時常常會用到,像是用 Fortify SCA 白箱掃描,或是 CI & CD 機制上。

BRANCH=master
git fetch --force
git reset --hard origin/"${BRANCH}"
git submodule sync --recursive
git submodule update --init --force
git clean --force --force -d -x
git checkout "${BRANCH}" --force

用了很多 --force 主要是要處理 force push 後的收拾 :o

其實如果想要處理的更好的話,可以在發生錯誤時改走 mv (保留屍體) + 重新 clone 的機制,並且發警報出來讓管理者事後研究,這樣發生問題當下還是可以先提供服務。

不過這個想法還只在腦袋裡還沒寫... XD

GitHub 提供新的 contribution (小綠點) 計算方式

以往 GitHub 在個人頁面上的 contribution 只會計算 public repository,現在則可以設定將 private repository 也統計進去:「More contributions on your profile」。

private repository 的部份只會顯示數量,不會公開任何細節,像是我用 incognito mode (無痕模式) 可以看到在沒有登入時的資訊:

但如果是登入後就會有詳細資料:

GitHub 大幅調漲企業方案

GitHub 推出以 user 數量計費的方案:「Introducing unlimited private repositories」。舊的方案可以參考在「web.archive.org」這邊記錄下來的內容。

這個方案下的個人帳號會大幅受益:原先最低消費的 USD$7/month 是 5 private repositories,現在變成 unlimited private repositories。

而企業方案將會大幅調漲,雖然現有的 Plan 還是存在,但有種開始殺雞的味道了。

以前 USD$200/month 可以買到 125 個 repository,現在只能給 22 個人用。同時因為 GitHub 對 deploy key 的限制,跨 repository 時無法重複使用同一把 key,就需要用到真正的 user account,這點就變成額外的成本了。

看了一下內部的數字,不是多一倍兩倍的費用,而是多一個數量級...

BitKeeper 的 Open Source 行為

LWN 上看到這個消息:「BitKeeper's open source release」,BitKeeper 網站上也已經看到 open source 的消息了。

從 2005 年跟 Linux 分家後,走了十年走到這條路... 在「This is to answer this question and all the "too late" comments.」這邊看到是這樣做出來的決定,看起來沒救了:

Git/Github has all the market share. Trying to compete with that just proved to be too hard. So rather than wait until we were about to turn out the lights, we decided to open source it while we still had money in the bank and see what happens. We've got about 2 years of money and we're trying to build up some additional stuff that we can charge for. We're also open to being doing work for pay to add whatever it is that some company wants to BK, that's more or less what we've been doing for the last 18 years.

Will it work? No idea. We have a couple of years to find out. If nothing pans out, open sourcing it seemed like a better answer than selling it off.

Xcode 7.3.1 總算更新了 Git...

在「Go upgrade Xcode. Fix your git security hole.」這邊看到 Xcode 7.3.1 的消息,在「Xcode 7.3.1 Release Notes」這邊列出了 7.3.1 的改變,其中 Git 總算是更新了:

Git has been updated to version 2.7.4 in order to improve security. (25181743)

參考「Git 的安全性問題」這邊,拖了一個多月啊...

Homebrew 會將安裝資訊送到 Google Analytics 上

Hacker News Daily 上看到 Homebrew 會將安裝資訊送到 Google Analytics 上面:「Homebrew's Anonymous Aggregate User Behaviour Analytics」。

opt-out 的方法有兩個,一個是環境變數,另外一個是透過 git 設定:

If after everything you've read you still wish to opt-out of Homebrew's analytics you may set HOMEBREW_NO_ANALYTICS=1 in your environment or run git config --file="$(brew --repository)/.git/config" --replace-all homebrew.analyticsdisabled true which will prevent analytics from ever being sent when either of them have been set.

Git 2.8 的平行下載 submodule 加速

Git 推出新版的時候,幾家 Git Hosting 都會撰文寫一些重要的進展,像是 GitHub 這次的內容:「Git 2.8 has been released」。

GitHub 這次說明平行下載的範例直接清楚表示出來功能:

git fetch --recurse-submodules --jobs=4

用 Google 找了一個 .gitmodules 裡面有很多筆的 repository 測了一下,的確是快了不少...

Git 的安全性問題

在「Remote Code Execution in all git versions (client + server) < 2.7.1: CVE-2016-2324, CVE-2016‑2315」這邊看到歡樂的 CVE-2016-2315CVE-2016-2324,屬於 RCE 類漏洞。

Git 2.7.1 之前的所有版本都有問題,看起來由於問題過於大條,在 2016/02/06 發表的「Git v2.7.1 Release Notes」沒有標出這兩個 CVE,讓所有 vendor 有時間升級。

不過看起來 GitLab 不在被通知的 vendor 裡面,很無奈的在 CVE 公開後馬上推出新版,需要升級到最新版本:「GitLab 8.5.7 Released」。

diff-so-fancy 工具

Hacker News Daily 上看到的工具:「diff-so-fancy」。

光是從 screenshot 仔細看,會發現漏掉了一些 minus 與 plus 的資訊 (中間有一段應該要顯示 -document 與 +this.element, false 的部份,只顯示了 plus 的部份),有可能是 bug 也有可能是 feature。

另外對於已經讀習慣 diff 輸出結果的人,反而要另外學習,至於這個 learning curve 值不值得就見仁見智了...