Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 97ADFEC32BA for ; Thu, 12 Apr 2012 19:03:13 -0300 (ADT) Received: from [2400:c400::113:212:99:188] (helo=svana.org) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SIS6f-0008OP-O6 for pgsql-hackers@postgresql.org; Thu, 12 Apr 2012 22:03:12 +0000 Received: from kleptog by svana.org with local (Exim 4.72) (envelope-from ) id 1SIS69-0003aL-AE; Fri, 13 Apr 2012 08:02:37 +1000 Date: Fri, 13 Apr 2012 00:02:37 +0200 From: Martijn van Oosterhout To: Alvaro Herrera Cc: Magnus Hagander , Tom Lane , Greg Smith , Robert Haas , Pg Hackers Subject: Re: Last gasp Message-ID: <20120412220236.GA12495@svana.org> Reply-To: Martijn van Oosterhout References:

<4F84D3A0.8010808@2ndQuadrant.com> <4F85573A.3070807@2ndQuadrant.com> <22532.1334154260@sss.pgh.pa.us> <1334156238-sup-9033@alvh.no-ip.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <1334156238-sup-9033@alvh.no-ip.org> X-PGP-Key-ID: Length=1024; ID=0x6F0B424C X-PGP-Key-Fingerprint: 34A8 8EAC F902 8C8D CA72 DCC7 201E DB34 6F0B 424C User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: kleptog@svana.org X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false X-Host-Lookup-Failed: Reverse DNS lookup failed for 2400:c400::113:212:99:188 (failed) X-Pg-Spam-Score: -1.1 (-) X-Archive-Number: 201204/657 X-Sequence-Number: 206460 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 11, 2012 at 12:00:39PM -0300, Alvaro Herrera wrote: > remote in their main PG tree, and so changesets could be pulled into the > same clone and cherry-picked into the master branch. If you're talking about a way of using git to support reviewing, the Gerrit tool has an interesting workflow. Essentially anything you want reviewed you push to a fake tag refs/for/master which always creates a new branch. As such you have a repository which contains every patch ever submitted, but it simultaneously tracks the parents so you know which version of the tree a patch was against. In the case of Postgres each entry in the CF app would have its own tag (say refs/cf/234) which would create a new patch for that entry. In the end accepted patches are cherry-picked onto the real tree. But because all patches are now in the same place you can build tooling around it easier, like testing: does this patch cherry-pick cleanly or is there a conflict. No merge commits, just using git purely as patch storage. (Note to make this work it has a git server emulation which may or may not be easy to do, but it's just a thought about workflow.) Have a nice day, --=20 Martijn van Oosterhout http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFPh1D8IB7bNG8LQkwRAmP8AJ9eEt9qO9CXwWEAxG7wePooDvD6vwCeMAzP F1plPRLc0rdxMHbxA2diUPE= =12B+ -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--