John Mandereau <john.mander...@gmail.com> writes: > Il giorno mar, 05/06/2012 alle 12.15 +0200, David Kastrup ha scritto: >> Change A redefines a function and its callers. >> >> Change B introduces another call of the function. >> >> No merge conflict. > > I see. You're right, in an ideal world change B would always produce a > build error,
No, each change is fine for itself. Just the merge fails. > but in the real world not always, and automatic merges tend to be less > examined by hand. We have Nodes and References in the documentation, and also examples. Now one could argue that translations are not introducing independent changes and so merges should be harmless. But translations have time lag. Original gets new functionality and documentation with examples, does not touch translation files. Translation translates. Original functionality is changed and examples are adapted. Translation is merged into original, introducing the translations with the examples not compiling anymore. No merge conflict: those changes appear the first time in translations, unfortunately at an inconvenient point of time where the executables no longer match. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
