Prev: [HACKERS] antisocial things you can do in git (but not CVS)
Next: [HACKERS] Finding slave WAL application time delay
From: Ron Mayer on 24 Jul 2010 10:02
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 <robertmhaas(a)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 <robertmhaas(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Eisentraut on 24 Jul 2010 13:28
On lör, 2010-07-24 at 07:02 -0700, Ron Mayer wrote:
> 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.

But then there would be commits in the main repository that were known
not good enough.


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

From: Andrew Dunstan on 24 Jul 2010 13:48


Peter Eisentraut wrote:
> On lör, 2010-07-24 at 07:02 -0700, Ron Mayer wrote:
>
>> 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.
>>
>
> But then there would be commits in the main repository that were known
> not good enough.
>
>

Yeah. Also, please bear in mind that our explicit aim here is to make
this change with a minimal disruption to existing work flows. So to all
those people who want to say "Look, you can now do all these cool
things" my answer is "Maybe we'll do them later, but not right now."

cheers

andrew

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

From: "Joshua D. Drake" on 24 Jul 2010 15:24
On Sat, 2010-07-24 at 13:48 -0400, Andrew Dunstan wrote:
>

> Yeah. Also, please bear in mind that our explicit aim here is to make
> this change with a minimal disruption to existing work flows. So to all
> those people who want to say "Look, you can now do all these cool
> things" my answer is "Maybe we'll do them later, but not right now."

Amen brother. Git is a universe different than CVS/SVN. Let's practice
KISS for a while shall we.

JD


--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt


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

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: [HACKERS] antisocial things you can do in git (but not CVS)
Next: [HACKERS] Finding slave WAL application time delay