When a file is not found, TreeEntry returns NotFound gRPC code. We don't want to track that in Sentry as it's a normal situation, a client error.

See https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4847.

Changelog: fixed

Upgrade Git version to v2.32.0

See merge request gitlab-org/gitaly!3573

With Git v2.32.0 having been released, let's upgrade Gitaly's
distributed version of Git to that version. The minimum required version
remains v2.31.0.

Changelog: changed

Upgrade the Git version we test against to v2.32.0. Given that we do not
yet bump the minimum required version, we also keep our jobs which test
against v2.31.1.

Auto-resolve other conflict scenarios when AllowConflicts is true

See merge request gitlab-org/gitaly!3504

Make gitaly supervisor configuration local

Closes #3651

See merge request gitlab-org/gitaly!3571

remote: Allow for in-memory remotes in UpdateRemoteMirror

Closes #3649

See merge request gitlab-org/gitaly!3566

Supervisor for the gitaly-ruby sidecar uses a package global
variable to store configuration. That causes issues in testing
as it produces a race conditions some times. The global variables
is an evil and we try to get rid of them. That change removes
the global variable and adds a constructor for the Config type.
Each test now uses a locally defined config variable and there is
no races on the global variable anymore.

Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/3651

In order to be able to show diffs on based on the merge ref, we
need to be able to automatically resolve conflicts when
UserMergeToRef is called with AllowConflicts set to true.

The mergeSubcommand.resolveConflicts has been modified to handle
scenarios wherein there is a missing side of a conflict (whether
it's our, their or the ancestor). This update is needed so we can
show the MR diff even if there are conflicts.

Before this change, we try to git-merge-file
(via conflicts.MergeFile) using 3 versions of a file from ancestor,
our, and their but that fails when one of them does not exist.
With this change, we only do that when 2 of them are present.

When 2 of those aren't present, we "manually" (in code) handle
conflict resolution by keeping the changes in conflict.Their and
rejecting other changes in conflict.Our and conflict.Ancestor as
we don't want them to show up.

Changelog: changed

Remove GrpcTreeEntryNotFound feature flag

See merge request gitlab-org/gitaly!3567

As we're about to phase out usage of on-disk remotes, all RPCs which
interact with them need to be converted to use in-memory remotes.
`UpdateRemoteMirror()` doesn't yet have the ability to use them.

Implement support for in-memory remotes by configuring the remote via a
set of Git configuration environment variables. Until downstream callers
have been converted from on-disk to in-memory remotes, both ways will
stay supported. Afterwards, we can drop the `RefName` parameter, which
really is the remote name.

Changelog: added

Changelog: removed

When generating Go code from protobuf messages, we always have a
mismatch between declared variables and generated identifiers. This
leads to a mismatch in generated documentation, where the variable
documentation does not start with the Go variable name as it is best
practice in Go. Because of this, we have started to use Go identifiers
in protobuf documentation to fix the discrepancy.

Update documentation of variables in messages related to
UpdateRemoteMirror to do so consistenly.

In order to allow callers to set up in-memory remotes, add the ability
to specify Git configuration for `Push()` and add a test which exercises
the new code. This functionality will be used in a subsequent commit.

We're about to add the ability to pass Git configuration entries to
`localrepo.Push()`. As the intended use case for this is to allow for
in-memory remotes when pushing, one of the new testcases will require
the ability to more tighlty control the push repository setup.

Refactor the test code to prepare for this by always having testcases
setup their own repositories.

Add a new option for the `GetRemoteReferences()` function that allows
the user to specify Git configuration entries. This easily allows the
caller to set up in-memory remotes, which we'll require in a subsequent
commit.

As we're about to add another new option which allows the setup of
in-memory remotes, a newly added testcase will require control over the
remote that is to be queried. Refactor the tests as a preparatory test
to explicitly specify their remote.

We'll need to add additional options to `GetRemoteReferences()` such
that we can set up in-memory remotes. As a preparatory step, convert the
function to receive a set of options instead of only patterns to make it
extensible.

No change in behaviour is expected from this commit.

[ci skip]

Fix branch created response with start branch name option

See merge request gitlab-org/gitaly!3562

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/288049

* Add extra test with start branch name

Changelog: fixed

Don't create records in storage_repositories on generation increment

Closes #3183

See merge request gitlab-org/gitaly!3557

The storage_repositories rows should be created only with CreateRepository
execution. We need to have more direct ways of managing database state
with on disk state. The replication should happen only for truly existing
storages. The repo existence check is now based on the database state after
7c517f28 (intercept RepositoryExists calls in Praefect, 2021-01-29), so
the error 'pq: duplicate key value violates unique constraint
"storage_repositories_pkey"' won't occur anymore.

Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/3183

Changelog: fixed

UserRebaseConfirmable: Remove feature flag

See merge request gitlab-org/gitaly!3553

Rolled out through:
5f81d1ed (operations: Implement UserRebaseConfirmable in Go, 2021-03-12),
UserRebaseConfirmable got a feature flag. This change removes the flag,
and allows the removal of the Ruby code in 14.1.

Changelog: changed

Expand configuration of direct database connection

See merge request gitlab-org/gitaly!3495

Remove on-by-default gitaly_go_user_update_branch feature flag

See merge request gitlab-org/gitaly!3475

Remove the the gitaly_go_user_update_branch feature flag that's been
on by default since my 866b0849 (Turn UserUpdateBranch in Go on by
default, 2021-03-23) merged in [1]. This brings us one step[2] closer
to removing this entirely.

As noted in [3] the underlying Ruby code is not being removed in this
commit, we'll have to wait until this change has been out for a while
to avoid the race condition described in that documentation.

1. https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3286
2. https://gitlab.com/gitlab-org/gitaly/-/issues/3472
3. https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/PROCESS.md#two-phase-ruby-to-go-rollouts

Changelog: changed

Ensure trailers use the right casing

See merge request gitlab-org/gitaly!3558

[ci skip]

logging: Drop topLevelGroup field

Closes #3639

See merge request gitlab-org/gitaly!3556

Changelog trailers are processed case-sensitively by the API. This
updates Danger so it errors when using incorrect casing, such as
`changelog` instead of `Changelog`.

See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62915 for more
information.

Create module v14 gitaly version

See merge request gitlab-org/gitaly!3525

Update default & secondary Go versions

See merge request gitlab-org/gitaly!3552

Changelog: changed

[ci skip]

[ci skip]

The topLevelGroup used to be important for logging as GitLab used to
store repositories in a directory structure mimicking the URL path. For
example `gitlab-org/gitaly` used to be stored at
`gitlab-org/gitaly.git`. Since 14.0 GitLab will no longer use the legacy
storage format this field will always read `@hashed`.

If a field is always a constant, why log it? This change stops logging
it.

Changelog: changed

[ci skip]