Robert Haas wrote:
> At the developer meeting, I promised to do the work of documenting how
> committers should use git. So here's a first version.
>
> http://wiki.postgresql.org/wiki/Committing_with_Git
>
> Note that while anyone is welcome to comment, I mostly care about
> whether the document is adequate for our existing committers, rather
> than whether someone who is not a committer thinks we should manage
> the project differently... that might be an interesting discussion,
> but we're theoretically making this switch in about a month, and
> getting agreement on changing our current workflow will take about a
> decade, so there is not time now to do the latter before we do the
> former. So I would ask everyone to consider postponing those
> discussions until after we've made the switch and ironed out the
> kinks. On the other hand, if you have technical corrections, or if
> you have suggestions on how to do the same things better (rather than
> suggestions on what to do differently), that would be greatly
> appreciated.
>
Well, either we have a terminology problem or a statement of policy that
I'm not sure I agree with, in point 2. IMNSHO, what we need to forbid
is commits that are not fast-forward commits, i.e. that do not have the
current branch head as an ancestor, ideally as the immediate ancestor.
Personally, I have a strong opinion that for everything but totally
trivial patches, the committer should create a short-lived work branch
where all the work is done, and then do a squash merge back to the main
branch, which is then pushed. This pattern is not mentioned at all. In
my experience, it is essential, especially if you're working on more
than one thing at a time, as many people often are.
cheers
andrew