Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Lessons from PostgreSQL's Git transition
Posted Oct 13, 2010 15:51 UTC (Wed) by petereisentraut (subscriber, #59453)
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".
Posted Oct 13, 2010 19:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Posted Oct 13, 2010 19:55 UTC (Wed) by dlang (✭ supporter ✭, #313)
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)
Posted Oct 13, 2010 22:42 UTC (Wed) by marcH (subscriber, #57642)
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.
Posted Oct 14, 2010 1:15 UTC (Thu) by dmarti (subscriber, #11625)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds