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 <[EMAIL PROTECTED]> wrote: > 2008/8/18 Carl D. Sorensen <[EMAIL PROTECTED]>: >> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
