Francisco Vila <[email protected]> writes: > 2011/12/13 Carl Sorensen <[email protected]>: >> >> >> On 12/13/11 7:06 AM, "[email protected]" <[email protected]> >> wrote: >> >>>Second draft uploaded; more robust with rebases instead of merge. >>> >>>Question: the old docs want translators to avoid rebasing for some >>>reason. Is that reason still valid? Because it would be very nice if >>>we didn't have to have a separate section of "git for translators". >>>http://lilypond.org/doc/v2.15/Documentation/contributor/pulling-and-rebasi >>>ng >> >> For some reason, which I don't understand, tranlsations are *always* added >> to master as a merge commit. >> >> For this reason, you don't want to do git pull -r >> >> Perhaps Francisco or John can shed more light on this subject. > > Not too much light, I'm afraid. John always merged. I just kept on > merging. I've got used to see merge commits for ages before I did > them by myself, so I never thought about modifying this workflow.
Translation work is long-running parallel work with little overlap with the main branch. Criss-cross merges are the pattern normally used for that as it minimizes the work for coordinating the branches and there is little point in creating a history that pretends that work on translations was done at a particular point of time. > If merge commits are undesirable for any reason and you have sorted > out on a clean batch of commands to run instead, I am all for changing > to that from now on. > > Merge commits are easy for me because you don't have to give an > explicit ID as an argument to the git command, only the branch name. I'd merge from master and into staging (which implies that in the long run, the history will just show criss-cross merges between master and translation). -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
