Re: Separate git branch for documentation

[Han-Wen Nienhuys]

If we start adding a lot of (occasional) contributors, I propose we
use the git.or.cz fork mechanism.  People can then publish their
changes, and it's easy for the maintainers to pull/cherry-pick thoses.

On Mon, Aug 18, 2008 at 5:01 PM, John Mandereau
<address@hidden> wrote:
> 2008/8/18 Carl D. Sorensen <address@hidden>:
>> Some time in the past, there was a request for a separate git
>> repository/branch[1] for documentation, with the idea that more people could
>> be approved for push access on the docs repository/branch than would be
>> approved for push access on the code.
>
> I have got no idea since my previous reply on this topic:
> http://lists.gnu.org/archive/html/lilypond-devel/2008-07/msg00349.html
> To sum up, I think we should keep current setup.
>
>
>> I think it would also be easier to have a separate branch for the docs
>> because it would facilitate debugging -- there are lots more docs commits
>> than code commits, so it's hard (for me at least) to do a good job of
>> bisecting when I'm looking for code changes.  If we can come up with some
>> method for isolating doc changes from code changes, I think it would be
>> helpful.
>
> As we finally should merge hypothetical documentation and code
> branches, all commits would be in the final branch anyway.  Han-Wen
> gave you a tip for isolating commits by directory, so this not a
> problem.
>
> Cheers,
> John
>
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen