| |||||||||||||
Lessons from PostgreSQL's Git transitionLessons from PostgreSQL's Git transitionPosted Oct 13, 2010 22:57 UTC (Wed) by marcH (subscriber, #57642)In reply to: Lessons from PostgreSQL's Git transition by fhuberts Parent article: Lessons from PostgreSQL's Git transition
> 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.
(Log in to post comments)
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.
Once everybody is properly accustomed to Git and what it can do we can start to think about other policies :-)
Hope that clarifies.
|
|||||||||||||