Skip to content
This repository was archived by the owner on Sep 3, 2019. It is now read-only.

How and when does Git for Windows get released

Johannes Schindelin edited this page Mar 29, 2014 · 9 revisions

We try to follow the git release schedule. When a core msysGit contributor reads that there is a new release, we try to update Git for Windows and incorporate changes from git.git.

The procedure can be outlined as follows:

git remote add junio https://github.com/git/git.git
git remote update junio origin
git fetch junio --tags
git checkout master
git pull origin master
git checkout -b tentative-foo
git branch -u origin/master
/share/msysgit/merging-rebase.sh foo # use --dry-run for testing

Here foo is a tag from the junio remote.

Once all conflicts are resolved, commit the changes.

We then run the tests. To get a compact output it helps to use the prove framework. So configure this by editing the /git/config.mak file as follows:

DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS=--timer --jobs 16

With this config in place, running make test runs the git tests under the prove test reporting aggregator. Once the tests complete, it will produce a simplified report of those tests that failed at the end. Typically, there are one or two failures which we try to investigate, or send a message to the msysGit mailing list mentioning which tests need to be shown some love.

Once the person starting the process (we are very loose on procedures, basically the first person having time, the others realize from "git fetch"ing that the process was started) is reasonably happy with the test suite, he or she makes the packages (using /share/WinGit/release.sh, /share/WinGit/portable-release.sh, /share/msysGit/net/release.sh and /share/msysGit/full/release.sh) and uploads them to GoogleCode and sends a message to the msysGit and the Git mailing list.

Clone this wiki locally