Le samedi 08 août 2009 à 13:55 -0600, Carl Sorensen a écrit :
> As a practical matter, -r first applies the changes that were made on origin
> (since your branch was checked out), then applies your changes on top of the
> current origin. The prevents an extra commit to merge your branch with
> origin, and keeps the git history cleaner.
> My recommendation is to always use it; it makes things much nicer.
I agree, except when docs in English are edited and translations
committishes are updated before edited docs in English are pushed.
Until now, only translators did this, but I'm going to add a feature (I
added it, but it's untested) that saves translators' work and only
require doc editors to run a script every time they make the same
changes in all languages. I'm adding a note in the CG about this.
If you don't understand the previous paragraph, just look at the head of
Besides this, there will always be merge commits between
lilypond/translation and master.
Le dimanche 09 août 2009 à 16:21 -0600, Carl Sorensen a écrit :
> Perfect! I hope I didn't mess up the translated docs too badly with my
> recent merge.
The only risk to mess up translated docs checking is in case you change
committishes that appear as comments at the head of each file. If this
is not clear enough in my CG addition, I'll rephrase it.
Le dimanche 09 août 2009 à 16:48 -0700, Graham Percival a écrit :
> Mao. So that means that we don't want to add
> git config --global branch.autosetuprebase always
> to the git setup, and we still have to tell people to do
> git pull -r
> instead of
> git pull
You didn't read the end of the paragraph I added in the CG. Actually,
we could make this option standard (except for people who merge master
and lilypond/translation), if and only if contributors are required to
use committishes in the head of translated files exclusively from
git.sv.gnu.org master branch. I'm thinking about adding a command (a
make target, actually) to update committishes in a way that meets this
> And even worse, the difference between those two commands
> depends on what kind of update the contributor is working on?!
Yes, except if we have the requirement explained above. As all
translators eventually mess up committishes (I already did), this would
Le lundi 10 août 2009 à 00:56 -0700, Graham Percival a écrit :
> After spending a while reading and re-reading your addition to the
> CG git stuff, it sounds like this only applies to translated docs
> -- i.e. as long as I don't mess with anything in de/ es/ fr/ etc/,
> it's safe to "git pull -r".
This is even broader: as long as you don't touch committishes in files
in de/ es/ fr/ etc., it's safe to "git pull -r". This distinction is
important, because doc contributors and developers are supposed to edit
docs in all languages in some cases, but after thinking again about it,
I needn't ask people other than translators and me to mess up with
> Is that correct? If so, I'll amend the warning to begin
> "translators: if you have changed committishes..."
You may amend this paragraph anyway.
Le lundi 10 août 2009 à 01:18 -0700, Graham Percival a écrit :
> We've lost 50% of potential contributors to the website because of
And we've lost the same percentage of potential French translators; I'm
sorry to remark that most of them who didn't spend the effort to master
Git and stopped contributing didn't spend much effort either to look for
accurate translation of musical and other technical terms, or even
respecting Texinfo format editing (I once got a translation in ODT!)
which is yet far simpler and comfortable than XML-based formats or PO.
Of course, simplifying version control system usage is still very
important to help translators who spend enough effort be more
Agreed. Many people are scared by just using command line, and I doubt
> IMO, the minimum is:
> - download and install git.
> - download source code. (copy&paste from CG 1.1.1)
> - update source code. (copy&paste from CG 1.2.2)
> - spend time editing the files. (this is what we want
> contributors to spend time doing!)
> - send us their changes. (copy&paste from CG 1.3.1)
> We want people working on lilypond, not working at understanding
we'll manage to get the procedure above simpler, so the only solution is
providing another way to contribute, e.g. a web interface that is not
read-only but that allows retrieval and submission of individual files
or file sets, or a GUI that makes command-line usage completely optional
but that offers a limited subset of Git features... like Johannes just
proposed ;-) I slightly prefer the Web interface option, as it's
cross-platform (GNU/Linux users can have difficulty with Git) and work
even with poor internet connexions that filter everything but DNS, HTTP
2009/8/10 Graham Percival <[hidden email]>:
> On Mon, Aug 10, 2009 at 10:50:09AM +0200, John Mandereau wrote:
>> Le lundi 10 août 2009 à 01:18 -0700, Graham Percival a écrit :
>> > We've lost 50% of potential contributors to the website because of
>> > git.
>> And we've lost the same percentage of potential French translators; I'm
>> sorry to remark that most of them who didn't spend the effort to master
>> Git and stopped contributing didn't spend much effort either to look for
>> accurate translation of musical and other technical terms, or even
>> respecting Texinfo format editing (I once got a translation in ODT!)
>> which is yet far simpler and comfortable than XML-based formats or PO.
> I agree that there's a correlation between willingness to learn
> git and quality of work. I'm not opposed to asking contributors
> to jump through _some_ hurdles; I just think we don't have the
> right balance yet. Off the top of my head, I'd guess that we want
> to discourage 25% of potential contributors.
>> > We want people working on lilypond, not working at understanding
>> > git.
>> Agreed. Many people are scared by just using command line...
Sometimes we forget that LilyPond is a command-line app. We already
are losing users that do not want to write code. So, if you hate
command lines or writing code, you'll hate LilyPond.
LilyPond code is very easy for beginners and I have proved it. Git
basics are only slightly more difficult. Potential contributors who
previously qualify as frequent LP users are very used to write code,
so they will find as a natural extension to learn git basics and start
making patches whenever they want.
I personally find more complicated to understand overrides or to write
lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png myfile.ly
to obtain a decent cropped PNG than
git pull + edit + git format-patch
to contribute to the docs.
Francisco Vila. Badajoz (Spain)
|Free forum by Nabble||Edit this page|