Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > On Tue, 12 Dec 2006, Sean Kelley wrote: > > > > > > > I was wondering if anyone could share ideas on how best to use GIT to > > > > handle releases for those working with a remote GIT repository? Do you > > > > create a branch and push it to the remote? Thus you have a new branch > > > > referencing the particular release? > > BTW, if the maintenance releases are sparse and long between, you can > actually create the branch from the tag, fix, and tag with the new version > number. No need to start the branches early. Indeed. I actually have a fancy (==~800 poorly written lines) Perl script that: * Creates a "build" git repository using objects/info/alternates. The user can reuse an existing directory if they have one. (Obviously reusing an existing directory is faster, less files to setup in the working directory.) * Offers the user a menu of top 10 most recent tags to choose as a base version. Tags are displayed first sorted by which tag is considered to be in which runtime environment (QA testing, end user testing, production release), then by tag date for those tags not in any specific environment. * Offers the user a menu of branches in a pre-configured namespace (e.g. refs/heads/ready) which have commits not yet merged into the selected base. Users can attempt to pull as many branches as they like, the script merges each in turn until none remain or the user says "build!". * Increments the last component of the 'version number' of the tag and makes an annotated tag object in the local build repository. * Runs the project's configured build command (from repo-config taken from builder.command variable). * If builder.command is successful pushes the tag back to the origin repository; if builder.command fails pushes the HEAD revision up as a branch (e.g. refs/heads/failed/foo) so that someone more skilled in the art of failed builds can look into the matter. The script is really meant for QA people to take in topic branches from developers and apply them to a specific version, test that new version, then ship that new version. Some of the QA people I work with aren't developers and have a somewhat difficult time making a build from source; this script makes it a pretty simple process. The version number incrementor is smart; its based off commit lineage. It can automatically create a "2.0.1" tag when "2.1" has already been made but "2.0.1" is a bugfix of "2" or "2.0". I should clean it up some and post it, just in case others may be interested. I'll try to do that this weekend. -- Shawn. - 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