Re: documentation for committing with git

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.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/