From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [DEV] New git workflow Date: Tue, 20 Mar 2012 20:20:13 +0100 Message-ID: <87haxjkrki.fsf@Rainer.invalid> References: <87mx7cf613.fsf@altern.org> <87fwd3ycsu.fsf@Rainer.invalid> <87ehsnr1w7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:36609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA4c3-0001TI-7R for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 15:21:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SA4bx-0002Qe-Qb for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 15:20:54 -0400 Received: from plane.gmane.org ([80.91.229.3]:59979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA4bx-0002QG-Jb for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 15:20:49 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SA4bt-0003t1-Ms for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 20:20:45 +0100 Received: from pd9eb298b.dip.t-dialin.net ([217.235.41.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 20:20:45 +0100 Received: from Stromeko by pd9eb298b.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 20:20:45 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien writes: > Agreed. What I want on top of this is a to have a branch where *every* > commit corresponds to a single release. Fair enough: a three-branch model with a release branch at the side of bugfixing and bleeding edge. > No. All hotfix branches should merge into master regularily. When > hotfix contains enough fixes for a bugfix release, then we merge it to > maint, and process with release. This is what I think is confusing: the bugfix branch (be it maint or any other) should always have the same _unless_ you want to track release specific bugfixes (which I don't think you do, but you tell me). If it changes name at every release, that just begs for a mix-up to happen when you are preparing for release and someone else tries to do one more fix. > My main goal is this: have a branch with one commit = one release. Why not name it release then and keep maint for fixes? You could even install that release branch retro-actively if you want. BTW, this also means you need to prepare the release on the hotfix branch, no fier-upper on the release allowed at all (since you would need to merge that back). But as I said before, clone the repo, branch off the 7.7 release or so and re-trace the following releases via cherry-pick according to that new development model. You will quickly learn if what you have to do feels right and if you commit to that model you will have practised the moves a few times already. Another thing that I'd recommend is to not work on the public repo _at all_ and specifically never push to it, especially not automatically. The public repo should be "bare" (without a work tree) and any work on the server should use a clone of that repo, just like anyone else. If you prepare the releases on a fresh clone apart from the development clone, you have a stable base to work from and can nuke with no consequences if something goes wrong. Git was designed to make merges easier, but they are hard and I still botch about every tenth that I try unless they are really trivial. Once the release repo is finished, have it reviewed and then pull from it on the public repo. The reason is that it is easy to push from the wrong branch onto the wrong target, but you really have to try to do that when pulling. You can be more liberal with the normal development and bugfixing work on the development repo, but it would still be a good idea to have commits reviewed and signed off by another person before they are pulled into public. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds