Message-ID: <4A2CD253.1000903@cheapcomplexdevices.com>
Date: Mon, 08 Jun 2009 01:56:51 -0700
From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Markus Wanner <markus@bluegap.ch>,
	Ron Mayer <rm_pg@cheapcomplexdevices.com>,
	Marko Kreen <markokr@gmail.com>, Greg Stark <stark@enterprisedb.com>,
	Andres Freund <andres@anarazel.de>, Aidan Van Dyk <aidan@highrise.ca>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Magnus Hagander <magnus@hagander.net>,
	Andrew Dunstan <andrew@dunslane.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL Developer meeting minutes up
References: <20090526144812.GC15213@yugib.highrise.ca>	
	<e51f66da0906030720u33d72d05y14ea5ce002cbaf1e@mail.gmail.com>	
	<20090604114610.808217tbogts0noi@mail.bluegap.ch>	
	<4A283A8D.8030600@cheapcomplexdevices.com>	
	<20090605090514.11712ntlvhi2deay@mail.bluegap.ch>	
	<2871.1244209112@sss.pgh.pa.us>	
	<603c8f070906050829m1eaaa969tff7ca85d04018c5a@mail.gmail.com>	
	<4888.1244216273@sss.pgh.pa.us>	
	<603c8f070906050859t41595fb1n17ed6084711b542e@mail.gmail.com>	
	<5543.1244218518@sss.pgh.pa.us>
	<603c8f070906050920h6842bf91q6ef2ec22e2948eb0@mail.gmail.com>
In-Reply-To: <603c8f070906050920h6842bf91q6ef2ec22e2948eb0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Robert Haas wrote:
> On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> ... but I'm not at all excited about cluttering the
>> long-term project history with a zillion micro-commits.  One of the
>> things I find most annoying about reviewing the current commit history
>> is that Bruce has taken a micro-commit approach to managing the TODO
>> list --- I was seldom so happy as the day that disappeared from CVS,
>> because of the ensuing reduction in noise level.

For better or worse, git also includes a command "git-rebase" that can
collapse such micro-commits into a larger one.

Quoting the git-rebase man page:
       A range of commits could also be removed with rebase. If we have the
       following situation:
               E---F---G---H---I---J  topicA
       then the command
           git-rebase --onto topicA~5 topicA~3 topicA
       would result in the removal of commits F and G:
               E---H´---I´---J´  topicA

While I wouldn't recommend using this for historical revisionism, I
imagine it could be useful during code-review time when the
micro-commits (from both the patch submitter and patch reviewer)
are interesting.  After the review, the commits could be collapsed
into meaningful-sized-chunks just before they're merged into the
official branches.