Carl Sorensen <c_soren...@byu.edu> writes: > In the case of your chords patch, I looked over each commit carefully > and I'm quite certain that if the build status of the final commit is > good, the build status of all previous commits will be good. So I'm > comfortable with pushing your chord patches as a set of commits. But > in general, I don't think that's a good idea.
We are still in the process of figuring out reasonably automatic procedures to admit merge commits (which have the advantage that for the purpose of bisection, the mainline jumps across the series in one piece). They require extra care when rebasing, and extra care is not easy to get at the average git literacy being around. So it is not clear whether it makes sense to try making them a regular part of our toolset. Of course, if most of the work can be automated without all too much pain, this might be worth trying out. The other option is _merging_ instead of fastforwarding dev/staging whenever we are not sure about every single of its components. That makes for a less straightforward history and makes it quite harder, if problems are detected afterwards, to revert the responsible commits without affecting the rest. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
