diff --git a/go/gen/proto/dolt/services/remotesapi/v1alpha1/chunkstore.pb.go b/go/gen/proto/dolt/services/remotesapi/v1alpha1/chunkstore.pb.go
index 52372f241b..c08906e3d8 100644
--- a/go/gen/proto/dolt/services/remotesapi/v1alpha1/chunkstore.pb.go
+++ b/go/gen/proto/dolt/services/remotesapi/v1alpha1/chunkstore.pb.go
@@ -36,6 +36,23 @@ const (
 	_ = protoimpl.EnforceVersion(protoimpl.MaxVersion - 20)
 )
 
+// A ChunkStore can request a client to implement a specific concurrency
+// control mechanism when updating a branch HEAD.
+//
+// This exists because passive remotes, like DoltHub, typically do not have
+// meaningful workingSets. When a client requests to push a branch HEAD to a
+// DoltHub remote, they have no visibility into the workingSet/ value for the
+// corresponding branch. It has historically been the case that clients ignore
+// it and just push the branch HEAD.
+//
+// On the other hand, when pushing to a running sql-server, not stomping
+// concurrent transaction is important, and the remote endpoint will want the
+// pushing client to ensure that it both checks that the branch's working set
+// is clean and that it updates the branch's working set appropriately if the
+// push is successful.
+//
+// Servers advertise which concurrency control mechanism they want in their
+// GetRepoMetadataResponse.
 type PushConcurrencyControl int32
 
 const (
diff --git a/proto/dolt/services/remotesapi/v1alpha1/chunkstore.proto b/proto/dolt/services/remotesapi/v1alpha1/chunkstore.proto
index d54a16f039..519bd616b0 100644
--- a/proto/dolt/services/remotesapi/v1alpha1/chunkstore.proto
+++ b/proto/dolt/services/remotesapi/v1alpha1/chunkstore.proto
@@ -201,6 +201,23 @@ message GetRepoMetadataRequest {
   string repo_path = 3;
 }
 
+// A ChunkStore can request a client to implement a specific concurrency
+// control mechanism when updating a branch HEAD.
+//
+// This exists because passive remotes, like DoltHub, typically do not have
+// meaningful workingSets. When a client requests to push a branch HEAD to a
+// DoltHub remote, they have no visibility into the workingSet/ value for the
+// corresponding branch. It has historically been the case that clients ignore
+// it and just push the branch HEAD.
+//
+// On the other hand, when pushing to a running sql-server, not stomping
+// concurrent transaction is important, and the remote endpoint will want the
+// pushing client to ensure that it both checks that the branch's working set
+// is clean and that it updates the branch's working set appropriately if the
+// push is successful.
+//
+// Servers advertise which concurrency control mechanism they want in their
+// GetRepoMetadataResponse.
 enum PushConcurrencyControl {
   PUSH_CONCURRENCY_CONTROL_UNSPECIFIED = 0;
   PUSH_CONCURRENCY_CONTROL_IGNORE_WORKING_SET = 1;