Re: CG: explanation of branches for the impatient (issue 5484043)

[David Kastrup]

Francisco Vila <address@hidden> writes:

> 2011/12/13 Carl Sorensen <address@hidden>:
>>
>>
>> On 12/13/11 7:06 AM, "address@hidden" <address@hidden>
>> 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