Re: documentation for committing with git

On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote:

> On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan <andrew(at)dunslane(dot)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
david(at)endpoint(dot)com