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