Re: German translation help file

[Johannes Schindelin]

Hi,

I'll just comment the German text in English, and leave the complete 
translation to you...

On Mon, 1 Jan 2007, Till Rettig wrote:

> Es muss git (und evtl. cogito) installiert sein, das letztere 
> Vereinfacht die Handhabung. Weitere Informationen finden sich auch noch 
> im LilyPond-Wiki 
> (http://lilypondwiki.tuxfamily.org/index.php?title=Translations_HOWTO).

I'd rather recommend against using cogito, as you are more or less bound 
to Linux with that. When I still had a working Mac, I never got it to run 
properly.

> Mit 
> 
> cg clone git://git.sv.gnu.org/lilypond.git#web/master
> 
> oder
> 
> git pull git://git.sv.gnu.org/lilypond.git/ web/master:

I'd rather bite the bullet and say

$ git clone -n git://git.sv.gnu.org/lilypond.git
$ git checkout -b myweb web/master

This does a little too much, but it is easier than

$ mkdir lilypond
$ cd lilypond
$ git init-db
$ git fetch git://git.sv.gnu.org/lilypond.git web/master:web/master
$ git checkout -b myweb web/master

> Es ist dabei wichtig, dass die erste Zeile das commitish enthält,

Why would it be important that the first line has a committish?

> git-rev-list HEAD | head -1

It is way easier to say

$ git rev-parse HEAD

But then, you really do not need that all that often. If you work locally, 
it is better to reference the commit by "HEAD" for the tip, "HEAD^" for 
its parent, "HEAD~2" for its grand-parent, "HEAD~3" for the great 
grand-parent, and so on.

> Darauf müssen die veränderten Dateien registriert werden.
> Wenn man nur Veränderungen vorgenommen hat, geschieht dies 
> folgendermaßen:
> 
> git-update-index <Dateiname>

No, you should say "git add <file>". "update-index" is considered core 
git, suitable for low-level scripts, not for human consumption.

> Wenn alle Arbeit getan ist, teilt man dem System mit, dass jetzt eine
> Revision stattgefunden hat:
> 
> git commit -a -m 'Eine Nachricht, die die Veränderungen beschreibt'

I'd rather tell the user that "-a" means that git will commit all the 
changes of all files it knows about (i.e. all that were present in the 
revision you forked from, plus all files you added), where change can also 
mean that the file was removed.

> Schließlich kann man aus den Veränderungen einen Patch erstellen:
> 
> git format-patch <committish>^
> 
> wobei committish wiederum die Nummer ist, die man vorher herausgefunden 
> hat.

It would be better to find the committish in another manner: When you 
forked from the upstream web/master, like I proposed ("git checkout -b 
myweb web/master"), you can do

$ git format-patch web/master

and you will get _all_ revisions which are not in the branch web/master, 
but in your current branch.

If you only want the patch which made the newest revision, do this:

$ git format-patch HEAD^

("HEAD" is whatever the tip of the current branch is, and "^" means its 
parent.)

You also should mention "git diff" to see what you actually changed since 
last committing, and "git commit --amend <file>" to add some changes to 
the current revision (this _rewrites_ the current HEAD, so you must not do 
that when you pushed that HEAD out already).

> Dabei werden einige Dateien erstellt, u.A. auch die Datei, die den Namen 
> hat, mit dem man git commit ausgeführt hat. Diese Datei wird dann per 
> E-Mail an lilypond-devel oder lilypond-user eingeschickt.

You should rather mention the commit in the email, but you don't need to 
write down all forty characters; 8 should be sufficient.

Hth,
Dscho