Conversation CommitService::CommitsByMessage

Feature Flag: gitaly_commits_by_message

Stages:

  • RPC Design: Create Issue #441 (closed)

  • Server Implementation: Create Issue #442 (closed) !263 (merged)

  • ~"Client Implementation": Create Issue #443 (closed) https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13268

  • ~"Acceptance Testing": #459 (closed) #573 (closed)

Blocked on:

  • https://gitlab.com/gitlab-org/gitlab-ce/issues/36893

Issues

  • #486 (closed) !303 (merged)

RPC Endpoints:

  • CommitService::CommitsByMessage

Known Client Routes:

  • Known client endpoints

app/models/Repository#find_commits_by_message

service CommitService {
  rpc CommitsByMessage(CommitsByMessageRequest) returns (stream CommitsByMessageResponse) {}
}

message CommitsByMessageRequest {
  Repository repository = 1;
  bytes revision = 2;
  // Must be >= 0
  int32 offset = 3;
  // Must be >= 0
  int32 limit = 4;
  // Must be non-empty
  string query = 5;
}

// One 'page' of the paginated response of CommitsByMessage
CommitsByMessageResponse {
  repeated GitCommit commits = 1;
}

Note: in the current implementation the last line is:

    git_log_results.map { |c| commit(c.chomp) }.compact

What happens here is that gitlab-ce is looking up commits by ID. This will give bad performance in the Gitaly scenario. Instead of returning the commit ID's as strings, we should return GitCommit Gitaly messages and turn them into Gitlab::Git::Commit instances. These can be fed into app/models/Repository#commit.

Edited Sep 15, 2017 by Andrew Newdigate
Assignee Loading
Time tracking Loading