User: Password:
|
|
Subscribe / Log in / New account

Lessons from PostgreSQL's Git transition

Lessons from PostgreSQL's Git transition

Posted Oct 12, 2010 20:30 UTC (Tue) by fhuberts (subscriber, #64683)
Parent article: Lessons from PostgreSQL's Git transition

Regarding 'no merge commits'...

We also don't allow them in our projects: everything that you want integrated into the main repository has to be rebased on the main repository branch on which you want it integrated.
This is to keep conflict resolution with the developer of the code, the one who actually know how to fix the conflict, rather than with the integrator.
It keeps integration cost very low and also keeps at linear history, which is again perfect for keeping features (consisting of multiple commits) together, which is again for for all kind of other things like bisecting and reverting.

Not so special this one thing :-)


(Log in to post comments)

Lessons from PostgreSQL's Git transition

Posted Oct 12, 2010 20:34 UTC (Tue) by daglwn (guest, #65432) [Link]

You're describing something different. The PostgreSQL folks aren't using the merge capability of git at all. They're doing manual diff+patch. This makes sense in a CVS environment where merging back to truck was incredibly, outrageously, ludicrously painful. Not so for git.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 12:12 UTC (Wed) by petereisentraut (subscriber, #59453) [Link]

The PostgreSQL folks may or may not be using the merge capability in their personal workflow. I certainly use it. We just require that what you apply to the master branch is rebased.

Lessons from PostgreSQL's Git transition

Posted Oct 12, 2010 20:41 UTC (Tue) by fhuberts (subscriber, #64683) [Link]

very nice read BTW.

Thanks for the writeup

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 4:24 UTC (Wed) by pdmccormick (subscriber, #69601) [Link]

I'd like to second that. I appreciate LWN.net's unique technical focus. Many thanks for the fascinating read.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 22:57 UTC (Wed) by marcH (subscriber, #57642) [Link]

> This is to keep conflict resolution with the developer of the code, the one who actually know how to fix the conflict, rather than with the integrator. It keeps integration cost very low...

I do not see how it makes a difference, could you please detail? I assume the "integrator" is a guy pulling from developers' repositories, correct?

> ... and also keeps at linear history, which is again perfect for keeping features (consisting of multiple commits) together, which is again for for all kind of other things like bisecting and reverting.

See above the interesting post from Ingo explaining... the exact opposite.

Lessons from PostgreSQL's Git transition

Posted Oct 14, 2010 5:23 UTC (Thu) by fhuberts (subscriber, #64683) [Link]

Yes the integrator is responsible for pushing to the central ('release') repo. We have only a few integrators per repo (we have a corporate setup).

I also agree with most of what Ingo says, but AFAIC there's not much difference. The thing is though that we have just switched over to Git and the devs have to get used to many things. Many devs are not of Linux kernel quality and do not develop their features in an ordely and structured fashion. Rebasing gives them the tool to clean up their mess before submitting it for review and integration.
Note that we still require small commits that build towards the feature, etc etc.

Once everybody is properly accustomed to Git and what it can do we can start to think about other policies :-)

Hope that clarifies.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds