Recent Features
| |||||||||||||
Lessons from PostgreSQL's Git transitionLessons from PostgreSQL's Git transitionPosted Oct 13, 2010 15:51 UTC (Wed) by petereisentraut (subscriber, #59453)In reply to: Lessons from PostgreSQL's Git transition by sbohrer Parent article: Lessons from PostgreSQL's Git transition
There is a lot of peer review happening before a patch is proposed for inclusion in the mainline. (Look for "commit fest" to learn about the details.)
Of course, you could separate those into chunks that can each be attributed to exactly one person. But why should you? I'd rather have one good patch by author A, based on an idea by B, prototype by C, reviewed by D, with additional documentation editing by E instead of a dozen crappy commits mixed with another dozen small cleanups "to serve the pure git workflow".
(Log in to post comments)
Lessons from PostgreSQL's Git transition Posted Oct 13, 2010 19:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Git allows you to do both. Just review the diff in its entirety, but commit it 'as-is'.
Lessons from PostgreSQL's Git transition Posted Oct 13, 2010 19:55 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
the git best practices method would be to have the work on this feature done in a separate branch.
the initial commit would be by author C (the prototype), with a follow-up patch(s) by author A, with credit to author B in the commit message or a comment in the code, a reviewed by: tag crediting author D (possibly in the merge commit), and an additional patch for the documentation by author E.
this then gets merged in and everyone can see what was done on this, these aren't mixed in with other commits for unrelated things (until after it's in the mainline, at which point fixes are going to be separate patches anyway)
Lessons from PostgreSQL's Git transition Posted Oct 13, 2010 22:42 UTC (Wed) by marcH (subscriber, #57642) [Link]
> ... instead of a dozen crappy commits mixed with another dozen small cleanups "to serve the pure git workflow".
Abilities to rewrite and clean up history is where git shines more than any other similar tool. Developers with some basic git experience never let crappy commits survive long enough to escape their local hard drives.
Lessons from PostgreSQL's Git transition Posted Oct 14, 2010 1:15 UTC (Thu) by dmarti (subscriber, #11625) [Link] ...and some of the "crappy" stuff committed locally turns out to have actually worked, so you're more likely to get in the habit of committing small changes. (I don't like the Subversion model where "commit it to revision control" and "everyone else on the project can point at your code and laugh" are the same.)
|
|||||||||||||