On Wed, Apr 11, 2012 at 18:29, Josh Kupershmidt <schmiddy@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> On 11 April 2012 15:35, Magnus Hagander <magnus@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/
