On Wed, Apr 11, 2012 at 18:29, Josh Kupershmidt <schmi...@gmail.com> wrote: > On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan <pe...@2ndquadrant.com> > wrote: >> On 11 April 2012 15:35, Magnus Hagander <mag...@hagander.net> wrote: > >>> For example, Thom (and others) could collect a number of typo fixes in >>> their own repo and then just ask for a merge.The advantage over just >>> staging multiple commits and then submitting a patch would be that >>> multiple people could work on it... >> >> This is hardly a radical idea at all - it's basically how git was >> really intended to be used at scale. Of course, unless some committer >> is going to make it their responsibility to merge those commits say >> every 3 months, there's no point in bothering. This could consolidate >> the number of typo commits to boot, as they could be rebased. TBH, I >> find it slightly embarrassing to have to ask a committer to fix a >> minor typo, and it's hardly reasonable to expect me to save my typos >> up. >> >> Big +1 from me. > > Particularly for the docs, it'd be nice to have more committer > bandwidth available, if there's a reasonable way to do so without > causing needless merge work for existing committers. Like Peter, I > hate to bother busy committers with trivial typofixes, and sometimes I > just don't bother sending such changes in, and they get lost :-( > > Maybe keeping doc/ as a 'git submodule' could work? Or, as Tom > suggests, adding a global committer who could focus on docs changes > would effectively solve the problem as well.
git submodule would be a really bad idea imho. Then you couldn't make a single commit that deals with both code and docs. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
