Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id ECA5F63307E for ; Sat, 6 Jun 2009 12:41:01 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 70826-05 for ; Sat, 6 Jun 2009 12:40:59 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from shaykin.bluegap.ch (shaykin.bluegap.ch [78.46.81.73]) by mail.postgresql.org (Postfix) with ESMTP id 438F96324F5 for ; Sat, 6 Jun 2009 12:40:58 -0300 (ADT) Received: from [192.168.2.103] (p5497615B.dip.t-dialin.net [::ffff:84.151.97.91]) (AUTH: CRAM-MD5 markus@bluegap.ch) by shaykin.bluegap.ch with esmtp; Sat, 06 Jun 2009 17:40:55 +0200 id 000000000255C021.000000004A2A8E07.00007CEB Message-ID: <4A2A8E06.2080204@bluegap.ch> Date: Sat, 06 Jun 2009 17:40:54 +0200 From: Markus Wanner User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Tom Lane CC: Ron Mayer , Marko Kreen , Greg Stark , Andres Freund , Aidan Van Dyk , Heikki Linnakangas , Magnus Hagander , Andrew Dunstan , PostgreSQL-development Subject: Re: PostgreSQL Developer meeting minutes up References: <20090526144812.GC15213@yugib.highrise.ca> <20090602162333.369974jcc3jpn3dx@mail.bluegap.ch> <20090602180702.15986cp384yo3l7q@mail.bluegap.ch> <20090603131004.12934iyrr4f7rlsc@mail.bluegap.ch> <4136ffa0906030508i2971790dk54a8203ee03ed196@mail.gmail.com> <4A266A56.2020703@anarazel.de> <4136ffa0906030701x200bf0e4o4c77fa3239062ca5@mail.gmail.com> <20090604114610.808217tbogts0noi@mail.bluegap.ch> <4A283A8D.8030600@cheapcomplexdevices.com> <20090605090514.11712ntlvhi2deay@mail.bluegap.ch> <2871.1244209112@sss.pgh.pa.us> In-Reply-To: <2871.1244209112@sss.pgh.pa.us> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200906/513 X-Sequence-Number: 139568 Hi, Tom Lane wrote: > I think it's already been made crystal clear that the people who > actually do this work don't do it that way, and are uninterested in > allowing their tools to force them to do it that way. That's well understood. > Patching from > HEAD back works better for us for a number of reasons, the main one > being that HEAD is the version of the code that's most "swapped into" > our awareness. Committing on the oldest back-branch first doesn't necessarily mean having to develop the patch there. > However, so long as we can have a separate working copy per branch, > I see no problem with preparing all the versions of a patch and then > committing them back-to-front. That's what I think as well. However, I bet git could help a lot with creating all the versions of a patch in the first place. You don't *need* to use that feature, but preserving the option could help. > What I'm not clear about is the > mechanics for doing that. If you create each of the patches individually, there's not much magic required from git. It should be trivial to commit those as merges. > Would someone explain exactly what the > steps should be to produce the nicest-looking git history? I fear the cherry-picking approach creates the "nicest-looking" history (especially to the CVS trained eye). Regards Markus Wanner