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

Lessons from PostgreSQL's Git transition

Lessons from PostgreSQL's Git transition

Posted Oct 12, 2010 20:18 UTC (Tue) by malefic (guest, #37306)
Parent article: Lessons from PostgreSQL's Git transition

> We will not use the author field in git to tag it with the patches original author ... we will require that author and committer are always set to the same thing, and we will then credit the author(s) (along with the reviewer(s)) in the commit message

What was the reasoning behind this? Why not retain the original author in the Author field? It's there for a reason. A number of repo analysis tools rely on the field to provide a proper picture contribution-wise.


(Log in to post comments)

Lessons from PostgreSQL's Git transition

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

Because usually a patch has more than one author or contributor, so it's not clear how to map that without skewing the picture that you are in fact pretending to unskew.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 14:32 UTC (Wed) by malefic (guest, #37306) [Link]

I see. In that case it would probably make sense to standardize the way people are listed in the commit message, e.g. by making use of tags: "Reviewed-by:", "Authored-by:" or "Reported-by:" in case of bugs.

Lessons from PostgreSQL's Git transition

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

Yeah, I think something like that will happen down the line.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 14:40 UTC (Wed) by sbohrer (guest, #61058) [Link]

Multiple contributors to a patch? Surely if there were multiple authors they each contributed small stand alone changes that could be sent as separate patches. Or is there a lot of pair programming going on?

Lessons from PostgreSQL's Git transition

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

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".

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 (subscriber, #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.)


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