libgit2 / libgit2/libgit2sharp

[RFC] Batched low level index operations

未關閉
#908 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

主要語言
C#
星號
3.5k
分支
925
PR 合併指標
30 天內沒有已合併 PR

描述

In the light of https://github.com/libgit2/libgit2sharp/pull/907, I was wondering if we should take this approach one step further.

Each call to repo.Stage() will

  • Perform a diff between the working directory and the Index in order to determine what additions/removals should be promoted to the staging area
  • Perform additions/deletions in the in memory Index
  • Eventually persist the in memory Index to the disk

Each call to repo.Index.Add() (or Remove()) will

  • Perform an addition (or a deletion) in the in memory Index
  • Persist the in memory Index to the disk

As such, invoking repo.Index.Add() or repo.Index.Remove() will be more efficient than a call to repo.Stage().

We want to allow the user to switch to the command line git.git, between each call to LibGit2Sharp, and find the repository in a coherent state. This is the requirement that compels us to persist the in-memory Index at the very end of each Index related method.

However, would clients of the library require to perform many sequential calls to the lower level methods repo.Index.Add()|Remove(), the Index would be persisted as part of each call. Which may not be very efficient.

Considering this above, would a need for an IndexUpdater exist?

We may expose something like in the Index type:

public virtual void Update(params Action<IndexUpdater>[] actions)

which would allow the client to write such code:

repo.Index.Update(i => i.Add(path), i => i.Remove(otherPath))

Or even some more elaborate custom thingies such as

private void StageAllAdditionsRemovalsAndModifications(IRepository repo)
{
    // Compare the Workdir against the Index without attempting at detecting Copies/Renames
    var changes = repo.Diff.Compare<TreeChanges>(null, true,
        compareOptions: new CompareOptions { Similarity = SimilarityOptions.None });

    repo.Index.Update(i =>
    {
        // We first clean the Index from unwanted entries...
        foreach (TreeEntryChanges treeEntryChanges in changes
            .Where(tec => tec.Status == ChangeKind.Deleted))
        {
            i.Remove(treeEntryChanges.Path);
        }

        // ...then insert in the Index the additions/modifications.
        foreach (TreeEntryChanges treeEntryChanges in changes
            .Where(tec => tec.Status == ChangeKind.Added || tec.Status == ChangeKind.Modified))
        {
            i.Add(treeEntryChanges.Path);
        }
    });
}

And allow us to only persist the Index only once, when all the actions have been performed by the IndexUpdater.

Thoughts?

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

先閱讀 PR #907 以及現有的 Index.Add() 和 Index.Remove() 入口點。將提議的 Index.Update/IndexUpdater API 與「repository 在呼叫之間保持一致」的要求進行比較;要視為完成,需要一個經 maintainer 核准的設計和明確的實作範圍,而本 RFC 尚未提供這些內容。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
csharp, git
領域
backend-api-design
Issue 類型
功能
難度
5/5
預估耗時
一週以上
活躍度
停滯
描述清晰度
需要釐清
新手友好度
25/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。