Robert Haas wrote:
> 
> If git had a place to store all the information we care about, that
> would be fine...
> 
> There's no "reviewer" header, and there's no concept that a patch
> might have come from the author (or perhaps multiple authors), but
> then have been adjusted by one or more reviewers and then frobnicated
> some more by the committer
> ...
> I don't think that non-linear history is an advantage in any
> situation.

ISTM we could have the best of both those worlds - linear history
and author&reviewer&committer information.

Instead of squashing every patch into a single commit, what if it got
squashed into a perhaps 3 separate commits -- one as submitted, one
as reviewed, and one as re-written by the committer.  History stays
linear; and you keep the most relevant parts of the history,
while dropping all the development brainstorming commits.

And ISTM the patch reviewer could be responsible for this squashing
so it's not much more work for the committer.

For example, instead of

    commit 351c0b92eca40c1a36934cf83fe75db9dc458cde
    Author: Robert Haas <robertmh...@gmail.com>
    Date:   Fri Jul 23 00:43:00 2010 +0000
    Avoid deep recursion when assigning XIDs to multiple levels of subxacts.
    Andres Freund, with cleanup and adjustment for older branches by me.

we'd see

    Author: Andreas Freund
    Date:   Fri Jul 23 00:43:00 2010 +0000
    Avoid deep recursion when assigning XIDs to multiple levels of subxacts.
    Path as originally submitted to commit fest

    Author: [Whomever the reviewer was]
    Date:   Fri Jul 23 00:43:00 2010 +0000
    Avoid deep recursion when assigning XIDs to multiple levels of subxacts.
    Patch marked read for committer by reviewer.

    Author: Robert Haas <robertmh...@gmail.com>
    Date:   Fri Jul 23 00:43:00 2010 +0000
    Avoid deep recursion when assigning XIDs to multiple levels of subxacts.
    Patch as rewritten by committer.

For a complex enough patch with many authors, the reviewer could choose to
keep an extra author commit or two to credit the extra authors.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to