是什么--loc=surv？我在任何地方都找不到它的任何定義。
為了在 git repo 中獲取貢獻統計資訊，我在 GitHub 上通過 casperdcl 找到了 git-fame 。它提供了每個貢獻者的貢獻圖表。我不認為 git 中插入和洗掉的總和是一個很好的規模。但是git-fame提供了另一個選項，稱為“幸存的代碼行”（--loc=surv）。但我不明白它是什么。我應該什么時候使用它？計算貢獻是否更好？
uj5u.com熱心網友回復：
首先，它不是“在 git 中”。它是casperdcl/git-fame在其v1.14.0 Q4 2020版本中添加的一項功能，并提交 2d34d84。
git-xxx任何名為(in ) 的可執行檔案$PATH都可以用 呼叫git xxx，給人xxx一種 Git 命令的錯覺。它不是。
其次，如第 59 期所示，它是默認選項。
我沒想到
git-fame和git-fame --loc=surviving- 之間有任何區別，而且沒有。
第三，它確實測量了提交之間仍然存在的行（尚未添加或洗掉），這允許：
- 關聯選項，例如
--ignore-rev或--ignore-revs-file=<f>（僅對幸存的行有效）， - 排除選項，例如
--cost（人月的時間成本（COCOMO）或人小時（基于提交時間），它僅基于增量（添加/洗掉的行）
uj5u.com熱心網友回復：
casperdcl的開發者在此問題上回答git-fame了以下問題：
它是否只計算該行的最后一次修訂？
--loc=surv確實算“只是該行的最后一個修訂版”。還包括-M和-C選項可能很有用。
尋找衡量我必須向開發人員支付多少費用的最佳方法。
這里是龍?? ...這些--cost選項可以根據https://github.com/casperdcl/git-fame#faqs使用不同的模型來猜測幾個小時和幾個月- 但請注意：
- 沒有辦法區分重構（可能是高價值）和重新格式化（可能是低價值）
- 生成的代碼（例如
package-lock.json）可能更好地通過提交次數來衡量，而功能代碼（例如train.py）可能更好地通過行數來衡量 - 洗掉
--loc=del（洗掉錯誤代碼）和過去的插入--loc=ins（不再存在但影響當前代碼背后的思想的行）也可能有用 - 一行代碼可能比 100 行更有價值。質量只能由人來衡量
- 審查其他人的代碼可能很有價值，但不會出現在 Git 歷史記錄中
- ...警告清單還在繼續
我充其量只能git fame作為幫助衡量貢獻真正價值的眾多方法之一。一種可能的策略是，如果您覺得自己無法進行審查，則讓人們互相審查對方的作業。我不建議僅根據提交/行的數量/速率來向人們付款。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/448000.html
標籤：混帐