Skip to content

Releases: kubernetes/git-sync

v4.2.3

06 May 20:11
df639fd
Compare
Choose a tag to compare

What's Changed

  • Base-image CVEs are resolved.

Full Changelog: v4.2.2...v4.2.3

Available at: registry.k8s.io/git-sync/git-sync:v4.2.3

v4.2.2

15 Apr 19:31
9d546c3
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v4.2.1...v4.2.2

Available at: registry.k8s.io/git-sync/git-sync:v4.2.2

v4.2.1

06 Feb 17:53
Compare
Choose a tag to compare

What's Changed

  • CVE fixes in base-image

Full Changelog: v4.2.0...v4.2.1

Available at: registry.k8s.io/git-sync/git-sync:v4.2.1

v4.2.0

17 Jan 06:30
Compare
Choose a tag to compare

Most important changes:

  • Try not to log credentials
  • Fix a bug with symlinks when --link is not under --root
  • Change the inner loop to be even simpler

What's Changed

  • Log less verbose flags in less verbose modes by @thockin in #837
  • Update the v3-to-v4 doc to cover some changes that I missed by @thockin in #843
  • Bug: links are relative to linkdir, not rootdir by @thockin in #848
  • Simplify inner loop: just fetch $ref by @thockin in #845
  • Bump actions/setup-go from 4 to 5 by @dependabot in #850
  • Try not to log credentials in repo URL by @thockin in #852
  • Bump to go 1.21 by @thockin in #858
  • Add '-F none' to e2e git SSH command for weird environments by @thockin in #859

Full Changelog: v4.1.0...v4.2.0

Available at: registry.k8s.io/git-sync/git-sync:v4.2.0

v4.1.0

14 Oct 23:51
Compare
Choose a tag to compare

This is minor overall, but includes a couple flag changes which warranted bumping the minor version.

  • --ssh is no longer needed (but still accepted)
  • --credential is new, to enable submodules with different usernames/passwords
  • Multiple SSH key are supported, to enable submodules with different keys
  • Better logging (minor)
  • Fix some corner cases for failure modes

Available at: registry.k8s.io/git-sync/git-sync:v4.1.0

What's Changed

  • fix: Fix backward compatibility of environment variables with bool type by @phil-park in #798
  • Add $GITSYNC_VERBOSE to set verbosity via env by @thockin in #805
  • Support multiple SSH keys for use in submodules by @thockin in #802
  • Print correct key on env-parse errors by @thockin in #812
  • Set core.askPass config for better auth-fail error by @thockin in #815
  • Deprecate --ssh - it's not really needed by @thockin in #822
  • Document V4 regression on --change-permissions by @thockin in #809
  • Add --credential flag for multiple username/password by @thockin in #803
  • Fix errors when parsing --repo for logging by @thockin in #830
  • fix: infinite bad loop caused by unexpected worktree directory removal by @bakome in #828
  • Logging: log syncCount and be less scary by @thockin in #835
  • Recover if wrong worktree HEAD by @thockin in #836

New Contributors

Full Changelog: v4.0.0...v4.1.0

v4.0.0

18 Aug 19:01
5e5035d
Compare
Choose a tag to compare

This is the first GA release of git-sync v4.

Available at: registry.k8s.io/git-sync/git-sync:v4.0.0

Git-sync v4 is a significant change from v3. It includes several flag changes
(though many of the old flags are kept for backwards compatibility), but more
importantly it fundamentally changes the way the internal sync-loop works.

It should be possible to upgrade a synced repo (e.g. in a volume) from git-sync
v3 to git-sync v4, but appropriate caution should be used for critical
deployments. We have a test which covers this, but there are many degrees of
config which we simply can't predict.

The v3 loop

The way git-sync v3.x works is sort of like how a human might work:

  1. git clone <repo> <branch>
  2. git fetch <remote>
  3. git checkout <ref>

This made the code somewhat complicated, since it had to keep track of whether
this was the first pass (clone) or a subsequent pass (fetch). This led to a
number of bugs related to back-to-back runs of git-sync, and some race
conditions.

The v4 loop

In v4.x the loop is simpler - every pass is the same. This takes advantage of
some idempotent behaviors (e.g. git init is safe to re-run) and uses git more
efficiently. Instead of cloning a branch, git-sync will now fetch exactly the
commit (by SHA) it needs. This transfers less data and closes the race
condition where a symbolic name can change after git ls-remote but before
git fetch.

Flags

The flag syntax parsing has changed in v4. git-sync v3 accept flags in Go's
own style: either -flag or --flag were accepted. git-sync v4 only accepts
long flag names in the more common two-dash style (--flag), and accepts short
(single-character) flags in the one-dash style (-v 2).

The following does not detail every flag available in v4 - just the one that
existed in v3 and are different in v4.

Verbosity: --v -> -v or --verbose

The change in flag parsing affects the old --v syntax. To set verbosity
either use -v or --verbose. For backwards compatibility, --v will be
used if it is specified.

Sync target: --branch and --rev -> --ref

The old --branch and --rev flags are deprecated in favor of the new --ref
flag. --ref can be either a branch name, a tag name, or a commit hash (aka
SHA). For backwards compatibility, git-sync will still accept the old flags
and try to set --ref from them.

|----------|---------|---------|------------------------------|
| --branch |  --rev  |  --ref  |            meaning           |
|----------|---------|---------|------------------------------|
|    ""    |   ""    | "HEAD"  | remote repo's default branch |
|  brname  |   ""    | brname  | remote branch `brname`       |
|  brname  | "HEAD"  | brname  | remote branch `brname`       |
|    ""    | tagname | tagname | remote tag `tagname`         |
|   other  |  other  |   ""    | error                        |
|----------|---------|---------|------------------------------|

Log-related flags

git-sync v3 exposed a number of log-related flags (e.g. -logtostderr). These
have all been removed. git-sync v4 always logs to stderr, and the only control
offered is the verbosity level (-v / --verbose).

Symlink: --dest -> --link

The old --dest flag is deprecated in favor of --link, which more clearly
conveys what it does. The allowed values remain the same, and for backwards
compatibility, --dest will be used if it is specified.

Loop: --wait -> --period

The old --wait flag took a floating-point number of seconds as an argument
(e.g. "0.1" = 100ms). The new --period flag takes a Go-style duration string
(e.g. "100ms" or "0.1s" = 100ms). For backwards compatibility, --wait will
be used if it is specified.

Failures: --max-sync-failures -> --max-failures

The new name of this flag is shorter and captures the idea that any
non-recoverable error in the sync loop counts as a failure. For backwards
compatibility, --max-sync-failures will be used if it is specified.

Timeouts: --timeout -> --sync-timeout

The old --timeout flag took an integer number of seconds as an argument. The
new --sync-timeout flag takes a Go-style duration string (e.g. "30s" or
"0.5m"). For backwards compatibility, --timeout will be used if it is
specified.

Permissions: --change-permissions -> --group-write

The old --change-permissions flag was poorly designed and not able to express
the real intentions (e.g. "allow group write" does not mean "set everything to
0775"). The new --group-write flag should cover what people ACTUALLY are
trying to do. The --change-permissions flag is no longer supported.

Manual: --man

The new --man flag prints a man-page style help document and exits.

Env vars

Most flags can also be configured by environment variables. In v3 the
variables all start with GIT_SYNC_. In v4 they all start with GITSYNC_,
though the old names are still accepted for compatibility.

Defaults

Depth

git-sync v3 would sync the entire history of the remote repo by default. v4
syncs just one commit, by default. This can be a significant performance and
disk-space savings for large repos. Users who want the full history can
specify --depth=0.

Logs

The logging output for v3 was semi-free-form text. Log output in v4 is
structured and rendered as strict JSON.

Root dir

git-sync v3 container images defaulted --root to "/tmp/git". In v4, that has
moved to "/git". Users who mount a volume and expect to use the default
--root must mount it on "/git".

Hooks

git-sync v3 could "lose" exechook and webhook calls in the face of the app
restarting. In v4, app startup is treated as a sync, even if the correct hash
was already present, which means that hooks are always called.

Other changes

git-sync v3 would allow invalidly formatted env vars (e.g. a value that was
expected to be boolean holding an integer) and just ignore them with
a warning. v4 requires that they parse correctly.

What's Changed since v4.0.0-rc5

Nothing!

Notable changes

Read more

v4.0.0-rc5

31 Jul 21:31
5e5035d
Compare
Choose a tag to compare
v4.0.0-rc5 Pre-release
Pre-release

Compared to RC4 this includes:

  • Fix permissions on /tmp in the container image

Converting from git-sync v3.x to v4.x

Git-sync v4 is a significant change from v3. It includes several flag changes
(though many of the old flags are kept for backwards compatibility), but more
importantly it fundamentally changes the way the internal sync-loop works.

It should be possible to upgrade a synced repo (e.g. in a volume) from git-sync
v3 to git-sync v4, but appropriate caution should be used for critical
deployments. We have a test which covers this, but there are many degrees of
config which we simply can't predict.

The v3 loop

The way git-sync v3.x works is sort of like how a human might work:

  1. git clone <repo> <branch>
  2. git fetch <remote>
  3. git checkout <ref>

This made the code somewhat complicated, since it had to keep track of whether
this was the first pass (clone) or a subsequent pass (fetch). This led to a
number of bugs related to back-to-back runs of git-sync, and some race
conditions.

The v4 loop

In v4.x the loop is simpler - every pass is the same. This takes advantage of
some idempotent behaviors (e.g. git init is safe to re-run) and uses git more
efficiently. Instead of cloning a branch, git-sync will now fetch exactly the
commit (by SHA) it needs. This transfers less data and closes the race
condition where a symbolic name can change after git ls-remote but before
git fetch.

Flags

The flag syntax parsing has changed in v4. git-sync v3 accept flags in Go's
own style: either -flag or --flag were accepted. git-sync v4 only accepts
long flag names in the more common two-dash style (--flag), and accepts short
(single-character) flags in the one-dash style (-v 2).

The following does not detail every flag available in v4 - just the one that
existed in v3 and are different in v4.

Verbosity: --v -> -v or --verbose

The change in flag parsing affects the old --v syntax. To set verbosity
either use -v or --verbose. For backwards compatibility, --v will be
used if it is specified.

Sync target: --branch and --rev -> --ref

The old --branch and --rev flags are deprecated in favor of the new --ref
flag. --ref can be either a branch name, a tag name, or a commit hash (aka
SHA). For backwards compatibility, git-sync will still accept the old flags
and try to set --ref from them.

|----------|---------|---------|------------------------------|
| --branch |  --rev  |  --ref  |            meaning           |
|----------|---------|---------|------------------------------|
|    ""    |   ""    | "HEAD"  | remote repo's default branch |
|  brname  |   ""    | brname  | remote branch `brname`       |
|  brname  | "HEAD"  | brname  | remote branch `brname`       |
|    ""    | tagname | tagname | remote tag `tagname`         |
|   other  |  other  |   ""    | error                        |
|----------|---------|---------|------------------------------|

Log-related flags

git-sync v3 exposed a number of log-related flags (e.g. -logtostderr). These
have all been removed. git-sync v4 always logs to stderr, and the only control
offered is the verbosity level (-v / --verbose).

Symlink: --dest -> --link

The old --dest flag is deprecated in favor of --link, which more clearly
conveys what it does. The allowed values remain the same, and for backwards
compatibility, --dest will be used if it is specified.

Loop: --wait -> --period

The old --wait flag took a floating-point number of seconds as an argument
(e.g. "0.1" = 100ms). The new --period flag takes a Go-style duration string
(e.g. "100ms" or "0.1s" = 100ms). For backwards compatibility, --wait will
be used if it is specified.

Failures: --max-sync-failures -> --max-failures

The new name of this flag is shorter and captures the idea that any
non-recoverable error in the sync loop counts as a failure. For backwards
compatibility, --max-sync-failures will be used if it is specified.

Timeouts: --timeout -> --sync-timeout

The old --timeout flag took an integer number of seconds as an argument. The
new --sync-timeout flag takes a Go-style duration string (e.g. "30s" or
"0.5m"). For backwards compatibility, --timeout will be used if it is
specified.

Permissions: --change-permissions -> --group-write

The old --change-permissions flag was poorly designed and not able to express
the real intentions (e.g. "allow group write" does not mean "set everything to
0775"). The new --group-write flag should cover what people ACTUALLY are
trying to do. The --change-permissions flag is no longer supported.

Manual: --man

The new --man flag prints a man-page style help document and exits.

Env vars

Most flags can also be configured by environment variables. In v3 the
variables all start with GIT_SYNC_. In v4 they all start with GITSYNC_,
though the old names are still accepted for compatibility.

Defaults

Depth

git-sync v3 would sync the entire history of the remote repo by default. v4
syncs just one commit, by default. This can be a significant performance and
disk-space savings for large repos. Users who want the full history can
specify --depth=0.

Logs

The logging output for v3 was semi-free-form text. Log output in v4 is
structured and rendered as strict JSON.

Root dir

git-sync v3 container images defaulted --root to "/tmp/git". In v4, that has
moved to "/git". Users who mount a volume and expect to use the default
--root must mount it on "/git".

Hooks

git-sync v3 could "lose" exechook and webhook calls in the face of the app
restarting. In v4, app startup is treated as a sync, even if the correct hash
was already present, which means that hooks are always called.

Other changes

git-sync v3 would allow invalidly formatted env vars (e.g. a value that was
expected to be boolean holding an integer) and just ignore them with
a warning. v4 requires that they parse correctly.

Available at: registry.k8s.io/git-sync/git-sync:v4.0.0-rc5

What's Changed since rc4

Full Changelog: v4.0.0-rc4...v4.0.0-rc5

v4.0.0-rc4

30 Jul 06:51
Compare
Choose a tag to compare
v4.0.0-rc4 Pre-release
Pre-release

Compared to RC3 this includes:

  • OCI image now correctly reports debian 12
  • Lint fixes
  • Fix a leaked goroutine when parsing git options
  • When credential refresh errors occur (e.g. askpass) we no longer try to sync

Converting from git-sync v3.x to v4.x

Git-sync v4 is a significant change from v3. It includes several flag changes
(though many of the old flags are kept for backwards compatibility), but more
importantly it fundamentally changes the way the internal sync-loop works.

It should be possible to upgrade a synced repo (e.g. in a volume) from git-sync
v3 to git-sync v4, but appropriate caution should be used for critical
deployments. We have a test which covers this, but there are many degrees of
config which we simply can't predict.

The v3 loop

The way git-sync v3.x works is sort of like how a human might work:

  1. git clone <repo> <branch>
  2. git fetch <remote>
  3. git checkout <ref>

This made the code somewhat complicated, since it had to keep track of whether
this was the first pass (clone) or a subsequent pass (fetch). This led to a
number of bugs related to back-to-back runs of git-sync, and some race
conditions.

The v4 loop

In v4.x the loop is simpler - every pass is the same. This takes advantage of
some idempotent behaviors (e.g. git init is safe to re-run) and uses git more
efficiently. Instead of cloning a branch, git-sync will now fetch exactly the
commit (by SHA) it needs. This transfers less data and closes the race
condition where a symbolic name can change after git ls-remote but before
git fetch.

Flags

The flag syntax parsing has changed in v4. git-sync v3 accept flags in Go's
own style: either -flag or --flag were accepted. git-sync v4 only accepts
long flag names in the more common two-dash style (--flag), and accepts short
(single-character) flags in the one-dash style (-v 2).

The following does not detail every flag available in v4 - just the one that
existed in v3 and are different in v4.

Verbosity: --v -> -v or --verbose

The change in flag parsing affects the old --v syntax. To set verbosity
either use -v or --verbose. For backwards compatibility, --v will be
used if it is specified.

Sync target: --branch and --rev -> --ref

The old --branch and --rev flags are deprecated in favor of the new --ref
flag. --ref can be either a branch name, a tag name, or a commit hash (aka
SHA). For backwards compatibility, git-sync will still accept the old flags
and try to set --ref from them.

|----------|---------|---------|------------------------------|
| --branch |  --rev  |  --ref  |            meaning           |
|----------|---------|---------|------------------------------|
|    ""    |   ""    | "HEAD"  | remote repo's default branch |
|  brname  |   ""    | brname  | remote branch `brname`       |
|  brname  | "HEAD"  | brname  | remote branch `brname`       |
|    ""    | tagname | tagname | remote tag `tagname`         |
|   other  |  other  |   ""    | error                        |
|----------|---------|---------|------------------------------|

Log-related flags

git-sync v3 exposed a number of log-related flags (e.g. -logtostderr). These
have all been removed. git-sync v4 always logs to stderr, and the only control
offered is the verbosity level (-v / --verbose).

Symlink: --dest -> --link

The old --dest flag is deprecated in favor of --link, which more clearly
conveys what it does. The allowed values remain the same, and for backwards
compatibility, --dest will be used if it is specified.

Loop: --wait -> --period

The old --wait flag took a floating-point number of seconds as an argument
(e.g. "0.1" = 100ms). The new --period flag takes a Go-style duration string
(e.g. "100ms" or "0.1s" = 100ms). For backwards compatibility, --wait will
be used if it is specified.

Failures: --max-sync-failures -> --max-failures

The new name of this flag is shorter and captures the idea that any
non-recoverable error in the sync loop counts as a failure. For backwards
compatibility, --max-sync-failures will be used if it is specified.

Timeouts: --timeout -> --sync-timeout

The old --timeout flag took an integer number of seconds as an argument. The
new --sync-timeout flag takes a Go-style duration string (e.g. "30s" or
"0.5m"). For backwards compatibility, --timeout will be used if it is
specified.

Permissions: --change-permissions -> --group-write

The old --change-permissions flag was poorly designed and not able to express
the real intentions (e.g. "allow group write" does not mean "set everything to
0775"). The new --group-write flag should cover what people ACTUALLY are
trying to do. The --change-permissions flag is no longer supported.

Manual: --man

The new --man flag prints a man-page style help document and exits.

Env vars

Most flags can also be configured by environment variables. In v3 the
variables all start with GIT_SYNC_. In v4 they all start with GITSYNC_,
though the old names are still accepted for compatibility.

Defaults

Depth

git-sync v3 would sync the entire history of the remote repo by default. v4
syncs just one commit, by default. This can be a significant performance and
disk-space savings for large repos. Users who want the full history can
specify --depth=0.

Logs

The logging output for v3 was semi-free-form text. Log output in v4 is
structured and rendered as strict JSON.

Root dir

git-sync v3 container images defaulted --root to "/tmp/git". In v4, that has
moved to "/git". Users who mount a volume and expect to use the default
--root must mount it on "/git".

Hooks

git-sync v3 could "lose" exechook and webhook calls in the face of the app
restarting. In v4, app startup is treated as a sync, even if the correct hash
was already present, which means that hooks are always called.

Other changes

git-sync v3 would allow invalidly formatted env vars (e.g. a value that was
expected to be boolean holding an integer) and just ignore them with
a warning. v4 requires that they parse correctly.

Available at: registry.k8s.io/git-sync/git-sync:v4.0.0-rc4

What's Changed since rc3

New Contributors

  • @Gemesil made their first contribution in #772
  • @justinsb made their first contribution in #784

Full Changelog: v4.0.0-rc3...v4.0.0-rc4

v3.6.9

28 Jul 20:16
2a29733
Compare
Choose a tag to compare

Small bug fixes and better errors

Available at: registry.k8s.io/git-sync/git-sync:v3.6.9

What's Changed

  • v3: Don't block on hooks when already synced + one-time by @thockin in #762
  • Handle errors from credential refresh (v3) by @thockin in #782

Full Changelog: v3.6.6...v3.6.9

v4.0.0-rc3

17 Jul 15:44
Compare
Choose a tag to compare
v4.0.0-rc3 Pre-release
Pre-release

v4 RC3. Compared to RC2 this includes:

  • Fix a bug with relative-path submodules
  • Debian bookworm base image
  • Smaller container images

Converting from git-sync v3.x to v4.x

Git-sync v4 is a significant change from v3. It includes several flag changes
(though many of the old flags are kept for backwards compatibility), but more
importantly it fundamentally changes the way the internal sync-loop works.

It should be possible to upgrade a synced repo (e.g. in a volume) from git-sync
v3 to git-sync v4, but appropriate caution should be used for critical
deployments. We have a test which covers this, but there are many degrees of
config which we simply can't predict.

The v3 loop

The way git-sync v3.x works is sort of like how a human might work:

  1. git clone <repo> <branch>
  2. git fetch <remote>
  3. git checkout <ref>

This made the code somewhat complicated, since it had to keep track of whether
this was the first pass (clone) or a subsequent pass (fetch). This led to a
number of bugs related to back-to-back runs of git-sync, and some race
conditions.

The v4 loop

In v4.x the loop is simpler - every pass is the same. This takes advantage of
some idempotent behaviors (e.g. git init is safe to re-run) and uses git more
efficiently. Instead of cloning a branch, git-sync will now fetch exactly the
commit (by SHA) it needs. This transfers less data and closes the race
condition where a symbolic name can change after git ls-remote but before
git fetch.

Flags

The flag syntax parsing has changed in v4. git-sync v3 accept flags in Go's
own style: either -flag or --flag were accepted. git-sync v4 only accepts
long flag names in the more common two-dash style (--flag), and accepts short
(single-character) flags in the one-dash style (-v 2).

The following does not detail every flag available in v4 - just the one that
existed in v3 and are different in v4.

Verbosity: --v -> -v or --verbose

The change in flag parsing affects the old --v syntax. To set verbosity
either use -v or --verbose. For backwards compatibility, --v will be
used if it is specified.

Sync target: --branch and --rev -> --ref

The old --branch and --rev flags are deprecated in favor of the new --ref
flag. --ref can be either a branch name, a tag name, or a commit hash (aka
SHA). For backwards compatibility, git-sync will still accept the old flags
and try to set --ref from them.

|----------|---------|---------|------------------------------|
| --branch |  --rev  |  --ref  |            meaning           |
|----------|---------|---------|------------------------------|
|    ""    |   ""    | "HEAD"  | remote repo's default branch |
|  brname  |   ""    | brname  | remote branch `brname`       |
|  brname  | "HEAD"  | brname  | remote branch `brname`       |
|    ""    | tagname | tagname | remote tag `tagname`         |
|   other  |  other  |   ""    | error                        |
|----------|---------|---------|------------------------------|

Log-related flags

git-sync v3 exposed a number of log-related flags (e.g. -logtostderr). These
have all been removed. git-sync v4 always logs to stderr, and the only control
offered is the verbosity level (-v / --verbose).

Symlink: --dest -> --link

The old --dest flag is deprecated in favor of --link, which more clearly
conveys what it does. The allowed values remain the same, and for backwards
compatibility, --dest will be used if it is specified.

Loop: --wait -> --period

The old --wait flag took a floating-point number of seconds as an argument
(e.g. "0.1" = 100ms). The new --period flag takes a Go-style duration string
(e.g. "100ms" or "0.1s" = 100ms). For backwards compatibility, --wait will
be used if it is specified.

Failures: --max-sync-failures -> --max-failures

The new name of this flag is shorter and captures the idea that any
non-recoverable error in the sync loop counts as a failure. For backwards
compatibility, --max-sync-failures will be used if it is specified.

Timeouts: --timeout -> --sync-timeout

The old --timeout flag took an integer number of seconds as an argument. The
new --sync-timeout flag takes a Go-style duration string (e.g. "30s" or
"0.5m"). For backwards compatibility, --timeout will be used if it is
specified.

Permissions: --change-permissions -> --group-write

The old --change-permissions flag was poorly designed and not able to express
the real intentions (e.g. "allow group write" does not mean "set everything to
0775"). The new --group-write flag should cover what people ACTUALLY are
trying to do. The --change-permissions flag is no longer supported.

Manual: --man

The new --man flag prints a man-page style help document and exits.

Env vars

Most flags can also be configured by environment variables. In v3 the
variables all start with GIT_SYNC_. In v4 they all start with GITSYNC_,
though the old names are still accepted for compatibility.

Defaults

Depth

git-sync v3 would sync the entire history of the remote repo by default. v4
syncs just one commit, by default. This can be a significant performance and
disk-space savings for large repos. Users who want the full history can
specify --depth=0.

Logs

The logging output for v3 was semi-free-form text. Log output in v4 is
structured and rendered as strict JSON.

Root dir

git-sync v3 container images defaulted --root to "/tmp/git". In v4, that has
moved to "/git". Users who mount a volume and expect to use the default
--root must mount it on "/git".

Hooks

git-sync v3 could "lose" exechook and webhook calls in the face of the app
restarting. In v4, app startup is treated as a sync, even if the correct hash
was already present, which means that hooks are always called.

Other changes

git-sync v3 would allow invalidly formatted env vars (e.g. a value that was
expected to be boolean holding an integer) and just ignore them with
a warning. v4 requires that they parse correctly.

Available at: registry.k8s.io/git-sync/git-sync:v4.0.0-rc3

What's Changed since rc2

Full Changelog: v4.0.0-rc2...v4.0.0-rc3