lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Francisco Vila
Subject: Re: CG: explanation of branches for the impatient (issue 5484043)
Date: Wed, 14 Dec 2011 02:21:22 +0100

2011/12/14 Francisco Vila <address@hidden>:
> 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

Note that the text talks about translation committishes.  Translators
need to know how an original file did change since he last updated his
translation. This is what committishes are for.  The 'make
check-translation' script does the task of displaying those
differences by means of a mark we put on each translated doc, which is
a ref to the commit ID of the original. So what we want to achieve
here is that our committishes always are refs to published originals
in Savannah, rather than to unpublished, local originals.  Otherwise
we'd be pushing translations that we are nor going able to track from
originals' changes.

How 'git pull' alone does get it and 'git pull -r' ruins it, is
something outside of my current level of knowledge.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]