git/.github, branch v2.29.2

Merge branch 'js/ci-ghwf-dedup-tests'

2020-10-09T04:53:26Z

The logic to skip testing on the tagged commit and the tag itself was not quite consistent which led to failure of Windows test tasks. It has been revamped to consistently skip revisions that have already been tested, based on the tree object of the revision. * js/ci-ghwf-dedup-tests: ci: do not skip tagged revisions in GitHub workflows ci: skip GitHub workflow runs for already-tested commits/trees

ci: skip GitHub workflow runs for already-tested commits/trees

2020-10-08T18:58:37Z

When pushing a commit that has already passed a CI or PR build successfully, it makes sense to save some energy and time and skip the new build. Let's teach our GitHub workflow to do that. For good measure, we also compare the tree ID, which is what we actually test (the commit ID might have changed due to a reworded commit message, which should not affect the outcome of the run). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

GitHub workflow: automatically follow minor updates of setup-msbuild

2020-10-07T16:54:53Z

It is the custom to follow minor updates of GitHub Actions automatically, by using the suffix `@v1`. Actions' maintainers will then update that `v1` ref to point to the newest. However, for `microsoft/setup-msbuild`, 889cacb6897 (ci: configure GitHub Actions for CI/PR, 2020-04-11) uses a very specific `@v1.0.0` suffix. In this instance, that is a problem: should `setup-msbuild` release a new version that intends to fix a critical bug, we won't know it, and we won't use it. Such a scenario is not theoretical. It is happening right now: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands Let's simplify our setup, allowing us to benefit from automatically using the newest v1.x. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: avoid ugly "failure" in the `ci-config` job

2020-09-02T19:21:45Z

In the common case where users have _not_ pushed a `ci-config` branch to configure which branches should be included in the GitHub workflow runs, there is a big fat ugly annotation about a failure in the run's log: X Check failure on line 1 in .github @github-actions github-actions / ci-config .github#L1 Process completed with exit code 128. The reason is that the `ci-config` job tries to clone that `ci-config` branch, and even if it is configured to continue on error, the annotation is displayed, and it is distracting. Let's just handle this on the shell script level, so that the job's step is not marked as a failure. Signed-off-by: Johannes Schindelin Acked-by: Jeff King Signed-off-by: Junio C Hamano

ci: fix indentation of the `ci-config` job

2020-09-02T19:21:41Z

The section added in e76eec35540f (ci: allow per-branch config for GitHub Actions, 2020-05-07) contains a `&&`-chain that connects several commands. The first command is actually so long that it stretches over multiple lines, and as per usual, the continuation lines are indented one more level than the first. However, the subsequent commands in the `&&`-chain were also indented one more level than the first command, which was almost certainly unintended. Signed-off-by: Johannes Schindelin Acked-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'am/ci-wsfix'

2020-08-31T22:49:46Z

Aesthetic fix to a CI configuration file. * am/ci-wsfix: ci: fix inconsistent indentation

ci: fix inconsistent indentation

2020-08-21T19:09:38Z

While YAML allows different indentation styles as long as each block is consistent, it is rather unusual to mix different indentations in a single file. Adjust to use two-space indentation everywhere. Signed-off-by: Adrian Moennich Signed-off-by: Junio C Hamano

Merge branch 'ss/cmake-build'

2020-08-12T01:04:13Z

CMake support to build with MSVC for Windows bypassing the Makefile. * ss/cmake-build: ci: modification of main.yml to use cmake for vs-build job cmake: support for building git on windows with msvc and clang. cmake: support for building git on windows with mingw cmake: support for testing git when building out of the source tree cmake: support for testing git with ctest cmake: installation support for git cmake: generate the shell/perl/python scripts and templates, translations Introduce CMake support for configuring Git

ci: modification of main.yml to use cmake for vs-build job

2020-06-26T17:08:46Z

Teach .github/workflows/main.yml to use CMake for VS builds. Modified the vs-test step to match windows-test step. This speeds up the vs-test. Calling git-cmd from powershell and then calling git-bash to perform the tests slows things down(factor of about 6). So git-bash is directly called from powershell to perform the tests using prove. NOTE: Since GitHub keeps the same directory for each job (with respect to path) absolute paths are used in the bin-wrapper scripts. GitHub has switched to CMake 3.17.1 which changed the behaviour of FindCURL module. An extra definition (-DCURL_NO_CURL_CMAKE=ON) has been added to revert to the old behaviour. In the configuration phase CMake looks for the required libraries for building git (eg zlib,libiconv). So we extract the libraries before we configure. To check for ICONV_OMITS_BOM libiconv.dll needs to be in the working directory of script or path. So we copy the dlls before we configure. Signed-off-by: Sibi Siddharthan Signed-off-by: Junio C Hamano

Merge branch 'es/advertise-contribution-doc'

2020-06-18T04:54:06Z

Doc updates. * es/advertise-contribution-doc: docs: mention MyFirstContribution in more places