On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote: > On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan <and...@dunslane.net> wrote: >> >> >> 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. > > Uh, that's going to create an actual merge commit, no? Or you mean > squash-merge-but-only-fast-forward? > > I *think* the docs is based off the pattern of the committer having > two repositories - one for his own work, one for comitting, much like > I assume all of us have today in cvs.
You can also do a rebase after the merge to remove the local merge commit before pushing. I tend to do this anytime I merge a local branch, just to rebase on top of the most recent origin/master. Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
