Graham Percival <[email protected]> writes: > On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote: >> But we still need to find a solution where I have a chance of getting >> work done. > > dev/staging > > I just realized that I forgot to add this to the proposal. I'll > do that later tonight and send an updated version. > > Or better yet -- dev/lexer-fixes. Suppose that (almost) all your > work for the past 2 weeks went onto that branch. You think you're > done, so ask if it's ok to merge with master. James tests it, > sends you the output of "make doc" failing; you work a bit more, > maybe revert something, then announce that you think it's working > now. James tests again -- and since this is a major merge, he > tests a completely blank build dir, doing a full make doc, etc -- > and this time it passes. Merge happens, git master doens't break, > much celebrations by everybody.
Well, git master breaks with Python errors right now (when just doing make all, while trying to generate man pages as far as I can tell). The merge would have been fine before that, short of the preexisting bug in the documentation I fixed and committed this morning. Whatever. By the way: reverting a merge commit (like I did) is not a really good idea. In the history, this revert looks like an ordinary commit. If you now remerge the branch at a later point of time, all old commits in this branch have already been merged according to git, and are not merged again. And go missing. So you need to revert the revert first. Ugh. That's really a big wart on the do-as-single-merge-commit approach. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
