Re: Last gasp

Martijn van Oosterhout <kleptog@svana.org>

From: Martijn van Oosterhout <kleptog@svana.org>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Magnus Hagander <magnus@hagander.net>, Tom Lane <tgl@sss.pgh.pa.us>, Greg Smith <greg@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-04-12T22:02:37Z
Lists: pgsql-hackers
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,
-- 
Martijn van Oosterhout   <kleptog@svana.org>   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