In our current CVS setup, we have two separate builds in Jenkins CI; one for the latest and greatest (head of "master" branch) and one for the last/current minor release of the latest major release. The revisions to include in the minor release build will be tagged with a tag we can call "next-minor-release" here. Individual files are branched as needed and the "next-minor-release" tag is moved onto the branch. The Continuous Integration job will fetch and build the "next-minor-release" tag. As part of a major release, the "next-minor-release" tag is moved to the head of the main branch again. When moving to GIT, the natural thing will be a hotfix branch originating from each major release. In order to have a fixed name for the current hotfix branch, primarily for the CI but also simplifying for developers working with hotfixes, it seems git symbolic-ref will do the trick. After the first major release we can do something like this in our bare repository whereto developers push and where from Jenkins pulls code to build: git symbolic-ref refs/heads/current-hotfix-branch refs/heads/release-1-hotfixes and after the next major release, we simply move the referece pointer, as such git symbolic-ref refs/heads/current-hotfix-branch refs/heads/release-2-hotfixes HOWEVER this seems to require that everyone fetching/pulling from that repo - Jenkins included - delete their local "current-hotfix-branch" tracking branch, and then refetch it. Is there an easier way to solve the CI problem, eliminating the need to explicitly deleting the tracking branch on all remote repos every time the symbolic ref is moved i.e. at every major release? How have others solved this? Do you simply reconfigure Jenkins every time...? Thanks in advance. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html