Commit gRPC message: encoding field
Gitaly v15.10 adds the encoding
field to the GitCommit
message:
Extract from the Git commit in Gitaly that introduced it:
~/heptapod/gitaly $ git log -n1 -p cf24112527 -- proto/*.proto
commit cf24112527408773814956ae6aaf94a8f4a41ad9
Author: arkn98 <2424696-arkn98@users.noreply.gitlab.com>
Date: Tue Mar 14 22:58:41 2023 -0400
catfile: Add encoding information to GitCommit
Currently, Gitaly doesn't return the `encoding` header, which is
populated by `git cat-file` when the commit message was encoded using a
non-UTF-8 encoding and the `i18n.commitEncoding` was set to that
encoding when the commit was made. This can cause clients to show
corrupted commit messages, as seen in [1]. This commit adds the
`encoding` field to the `GitCommit` proto.
1. https://gitlab.com/gitlab-org/gitlab/-/issues/20058
Fixes: https://gitlab.com/gitlab-org/gitaly/-/issues/836
Changelog: added
Signed-off-by: arkn98 <2424696-arkn98@users.noreply.gitlab.com>
diff --git a/proto/shared.proto b/proto/shared.proto
index e2c2a41b7..7ca3e1ee4 100644
--- a/proto/shared.proto
+++ b/proto/shared.proto
@@ -128,6 +128,11 @@ message GitCommit {
// referenced_by contains fully-qualified reference names (e.g refs/heads/main)
// that point to the commit.
repeated bytes referenced_by = 12; // protolint:disable:this REPEATED_FIELD_NAMES_PLURALIZED
+ // The encoding of the commit message. This field will only be present if
+ // `i18n.commitEncoding` was set to a value other than "UTF-8" at the time
+ // this commit was made.
+ // See: https://git-scm.com/docs/git-commit#_discussion
+ string encoding = 13;
}
// This comment is left unintentionally blank.
I'm not sure if that kind of information is available in Mercurial.
The comment suggests that the situation could be no worse than it already is if we don't fill it, but perhaps some fallbacks will be removed in the Rails app or other clients because the decoding has become more reliable (yet obviously not 100% guaranteed).