[PATCH 2/2] Translate the tutorial to Brazillian Portuguese.

[PATCH 2/2] Translate the tutorial to Brazillian Portuguese.

[Thadeu Lima de Souza Cascardo]

---
 Documentation/pt/gittutorial.txt |  679 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 679 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/pt/gittutorial.txt

diff --git a/Documentation/pt/gittutorial.txt b/Documentation/pt/gittutorial.txt
new file mode 100644
index 0000000..25bee03
--- /dev/null
+++ b/Documentation/pt/gittutorial.txt
@@ -0,0 +1,679 @@
+gittutorial(7)
+==============
+
+NAME
+----
+gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
+
+Este tutorial explica como importar um novo projeto para o git,
+adicionar mudanças a ele, e compartilhar mudanças com outros
+desenvolvedores.
+
+If, ao invés disso, você está interessado primariamente em usar git para
+obter um projeto, por exemplo, para testar a última versão, você pode
+preferir começar com os primeiros dois capítulos de
+link:user-manual.html[O Manual do Usuário Git].
+
+Primeiro, note que você pode obter documentação para um comando como
+`git log --graph` com:
+
+------------------------------------------------
+$ man git-log
+------------------------------------------------
+
+ou:
+
+------------------------------------------------
+$ git help log
+------------------------------------------------
+
+Com a última forma, você pode usar o visualizador de manual de sua
+escolha; veja linkgit:git-help[1] para maior informação.
+
+É uma boa idéia se introduzir ao git com seu nome e endereço público de
+email antes de fazer qualquer operação. A maneira mais fácil de fazê-lo
+é:
+
+------------------------------------------------
+$ git config --global user.name "Seu Nome Vem Aqui"
+$ git config --global user.email voce@seudominio.exemplo.com
+------------------------------------------------
+
+
+Importando um novo projeto
+-----------------------
+
+Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.
+Você pode colocá-lo sob controle de revisão git como a seguir.
+
+------------------------------------------------
+$ tar xzf project.tar.gz
+$ cd project
+$ git init
+------------------------------------------------
+
+Git irá responder
+
+------------------------------------------------
+Initialized empty Git repository in .git/
+------------------------------------------------
+
+Você agora iniciou seu diretório de trabalho--você deve ter notado um
+novo diretório criado, com o nome de ".git".
+
+A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
+arquivos sob o diretório corrente (note o '.'), com 'git-add':
+
+------------------------------------------------
+$ git add .
+------------------------------------------------
+
+Este instantâneo está agora armazenado em uma área temporária que o git
+chama de "index" ou índice. Você pode permanetemente armazenar o
+conteúdo do índice no repositório com 'git-commit':
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+Isto vai te pedir por uma mensagem de commit. Você agora gravou sua
+primeira versão de seu projeto no git.
+
+Fazendo mudanças
+--------------
+
+Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao
+índice:
+
+------------------------------------------------
+$ git add file1 file2 file3
+------------------------------------------------
+
+Você está agora pronto para fazer o commit. Você pode ver o que está
+para ser gravado usando 'git-diff' com a opção --cached:
+
+------------------------------------------------
+$ git diff --cached
+------------------------------------------------
+
+(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças
+que você tenha feito mas ainda não adicionou ao índice.) Você também
+pode obter um breve sumário da situação com 'git-status':
+
+------------------------------------------------
+$ git status
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#	modified:   file1
+#	modified:   file2
+#	modified:   file3
+#
+------------------------------------------------
+
+Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,
+adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas
+mudanças com:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e,
+então, gravar a nova versão do projeto.
+
+Alternativamente, ao invés de executar 'git-add' antes, você pode usar
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+o que irá automaticamente notar quaisquer arquivos modificados (mas não
+novos), adicioná-los ao índices, e gravar, tudo em um único passo.
+
+Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa
+idéia começar a mensagem com uma simples e curta (menos de 50
+caracteres) linha sumarizando a mudança, seguida de uma linha em branco
+e, então, uma descrição mais detalhada.  Ferramentas que transformam
+commits em email, por exemplo, usam a primeira linha no campo de
+cabeçalho Subject: e o resto no corpo.
+
+Git rastreia conteúdo, não arquivos
+----------------------------
+
+Muitos sistemas de controle de revisão provêem um comando `add` que diz
+ao sistema para começar a rastrear mudanças em um novo arquivo.  O
+comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é
+usado tanto para arquivos novos e arquivos recentemente modificados, e
+em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena
+o conteúdo no índice, pronto para inclusão do próximo commit.
+
+Visualizando história do projeto
+-----------------------
+
+Em qualquer ponto você pode visualizar a história das suas mudanças
+usando
+
+------------------------------------------------
+$ git log
+------------------------------------------------
+
+Se você também quer ver a diferença completa a cada passo, use
+
+------------------------------------------------
+$ git log -p
+------------------------------------------------
+
+Geralmente, uma visão geral da mudança é útil para ter a sensação de
+cada passo
+
+------------------------------------------------
+$ git log --stat --summary
+------------------------------------------------
+
+Gerenciando "branches"/ramos
+-----------------
+
+Um simples repositório git pode manter múltiplos ramos de
+desenvolvimento.  Para criar um novo ramo chamado "experimental", use
+
+------------------------------------------------
+$ git branch experimental
+------------------------------------------------
+
+Se você executar agora
+
+------------------------------------------------
+$ git branch
+------------------------------------------------
+
+você vai obter uma lista de todos os ramos existentes:
+
+------------------------------------------------
+  experimental
+* master
+------------------------------------------------
+
+O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o
+ramo padrão que foi criado pra você automaticamente.  O asterisco marca
+o ramo em que você está atualmente; digite
+
+------------------------------------------------
+$ git checkout experimental
+------------------------------------------------
+
+para mudar para o ramo experimental.  Agora edite um arquivo, grave a
+mudança, e mude de volta para o ramo master:
+
+------------------------------------------------
+(edita arquivo)
+$ git commit -a
+$ git checkout master
+------------------------------------------------
+
+Verifique que a mudança que você fez não está mais visível, já que ela
+foi feita no ramo experimental e você está de volta ao ramo master.
+
+Você pode fazer uma mudança diferente no ramo master:
+
+------------------------------------------------
+(edit file)
+$ git commit -a
+------------------------------------------------
+
+neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em
+cada um.  Para unificar as mudanças feitas no experimental para o
+master, execute
+
+------------------------------------------------
+$ git merge experimental
+------------------------------------------------
+
+Se as mudanças não conflitam, está pronto.  Se existirem conflitos,
+marcadores serão deixados nos arquivos problemáticos exibindo o
+conflito;
+
+------------------------------------------------
+$ git diff
+------------------------------------------------
+
+vai exibir isto.  Após você editar os arquivos para resolver os
+conflitos,
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+irá gravar o resultado da unificação. Finalmente,
+
+------------------------------------------------
+$ gitk
+------------------------------------------------
+
+vai mostrar uma bela representação gráfica da história resultante.
+
+Neste ponto você pode remover seu ramo experimental com
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+Este comando garante que as mudanças no ramo experimental já estão no
+ramo atual.
+
+Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode
+sempre remover o ramo com
+
+-------------------------------------
+$ git branch -D crazy-idea
+-------------------------------------
+
+Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar
+alguma coisa.
+
+Usando git para colaboração
+---------------------------
+
+Suponha que Alice começou um novo projeto com um repositório git em
+/home/alice/project, e que Bob, que tem um diretório home na mesma
+máquina, quer contribuir.
+
+Bob começa com:
+
+------------------------------------------------
+bob$ git clone /home/alice/project myrepo
+------------------------------------------------
+
+Isso cria um novo diretório "myrepo" contendo um clone do repositório de
+Alice.  O clone está no mesmo pé que o projeto original, possuindo sua
+própria cópia da história do projeto original.
+
+Bob então faz algumas mudanças e as grava:
+
+------------------------------------------------
+(editar arquivos)
+bob$ git commit -a
+(repetir conforme necessário)
+------------------------------------------------
+
+Quanto está pronto, ele diz a Alice para puxar as mudanças do
+repositório em /home/bob/myrepo.  Ela o faz com:
+
+------------------------------------------------
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
+------------------------------------------------
+
+Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice.
+Se Alice fez suas próprias mudanças no intervalo, ela, então, pode
+precisar corrigir manualmente quaiquer conflitos.  (Note que o argumento
+"master" no comando acima é, de fato, desnecessário, já que é o padrão.)
+
+O comando "pull" executa, então, duas operações: ele obtém mudanças de
+um ramo remoto, e, então, as unifica no ramo atual.
+
+Note que, em geral, Alice gostaria que suas mudanças locais fossem
+gravadas antes de iniciar este "pull".  Se o trabalho de Bobo conflita
+com o que Alice fez desde que suas histórias se ramificaram, Alice irá
+usar seu diretório de trabalho e o índice para resolver conflitos, e
+mudanças locais existentes irão interferir com o processo de resolução
+de conflitos (git ainda irá realizar a obtenção mas irá se recusar a
+unificar --- Alice terá que se livrar de suas mudanças locais de alguma
+forma e puxar de novo quando isso acontecer).
+
+Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando
+"fetch"; isto permite Alice inspecionar o que Bob fez, usando um símbolo
+especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa
+que vale puxar, assim:
+
+------------------------------------------------
+alice$ git fetch /home/bob/myrepo master
+alice$ git log -p HEAD..FETCH_HEAD
+------------------------------------------------
+
+Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.
+A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é
+alcançável de FETCH_HEAD mas exclua tudo que é alcançável de HEAD. Alcie
+já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob tem
+em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.
+
+Se Alice quer visualizar o que Bob fez desde que suas história
+ramificaram, ela pode disparar o seguinte comando:
+
+------------------------------------------------
+$ gitk HEAD..FETCH_HEAD
+------------------------------------------------
+
+Isto usar a mesma notação de intervaldo que vimos antes com 'git log'.
+
+Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela
+pode usar a forma com três pontos ao invés da forma com dois pontos:
+
+------------------------------------------------
+$ gitk HEAD...FETCH_HEAD
+------------------------------------------------
+
+Isto significa "mostre tudo que é alcançavel de qualquer um, mas exclua
+tudo que é alcançavel a partir de ambos".
+This means "show everything that is reachable from either one, but
+exclude anything that is reachable from both of them".
+
+Por favor, note que essas notações de intervalo podem ser usadas tanto
+com gitk quanto com "git log".
+
+Apoós inspecionar o que Bob fez, se não há nada urgente, Alice pode
+decidir continuar trabalhando sem puxar de Bob.  Se a história de Bob
+tem alguma coisa que Alice precisa imediatamente, Alice pode optar por
+separar seu trabalho em progresso primeiro, fazer um "pull", e, então,
+finalmente, retomar seu trabalho em progresso em cima da história
+resultante.
+
+Quanto você está trabalhando em um pequeno grupo unido, não é incomum
+interagir com o mesmo repositório várias e várias vezes.  Definindo um
+repositório remoto antes de tudo, você pode fazê-lo mais facilmente:
+
+------------------------------------------------
+alice$ git remote add bob /home/bob/myrepo
+------------------------------------------------
+
+Com isso, Alice pode executar a primeira parte da operação "pull" usando
+o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,
+usando:
+
+-------------------------------------
+alice$ git fetch bob
+-------------------------------------
+
+Diferente da forma longa, quando Alice obteve de Bob usando um
+repositório remoto antes definido com 'git-remote', o que foi obtido é
+armazenado um ramo remoto, neste caso `bob/master`.  Então, após isso:
+
+-------------------------------------
+alice$ git log -p master..bob/master
+-------------------------------------
+
+mostra uma lista de todas as mudanças que Bob fez desde que ramificou do
+ramo master de Alice.
+
+Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:
+
+-------------------------------------
+alice$ git merge bob/master
+-------------------------------------
+
+Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,
+assim:
+
+-------------------------------------
+alice$ git pull . remotes/bob/master
+-------------------------------------
+
+Note que 'git pull' sempre unifica ao ramo atual, independente do que
+mais foi dado na linha de comando.
+
+Depois, Bob pode atualizar seu repositório com as últimas mudanças de
+Alice, usando
+
+-------------------------------------
+bob$ git pull
+-------------------------------------
+
+Note que ele não precisa dar o caminho do repositório de Alice; quando
+Bob clonou seu repositório, o git armazenou a localização de seu
+repositório na configuração do repositório, e essa localização é usada
+para puxar:
+
+-------------------------------------
+bob$ git config --get remote.origin.url
+/home/alice/project
+-------------------------------------
+
+(A configuração completa criada por 'git-clone' é visível usando `git
+config -l`, e a página de manual linkgit:git-config[1] explica o
+significado de cada opção.)
+
+Git também mantém uma cópia limpa do ramo master de Alice sob o nome
+"origin/master":
+
+-------------------------------------
+bob$ git branch -r
+  origin/master
+-------------------------------------
+
+Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode
+executar clones e puxar usando o protocolo ssh:
+
+-------------------------------------
+bob$ git clone alice.org:/home/alice/project myrepo
+-------------------------------------
+
+Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou
+http; veja linkgit:git-pull[1] para detalhes.
+
+Git pode também ser usado em um modo parecido com CVS, com um
+repositório central para o qual que vários usuários empurram
+modificações; veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].
+
+Explorando história
+-----------------
+
+A história no git é representada como uma série de commits
+interrelacionados.  Nós já vimos que o comando 'git-log' pode listar
+esses commits. Note que a primeira linha de cama entrada no log também
+dá o nome para o commit:
+
+-------------------------------------
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date:   Tue May 16 17:18:22 2006 -0700
+
+    merge-base: Clarify the comments on post processing.
+-------------------------------------
+
+Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este
+commit.
+
+-------------------------------------
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+-------------------------------------
+
+Mas há outras formas de se referir a commits.  Você pode usar qualquer
+parte inicial do nome que seja longo o bastante para unicamente
+identificar o commit:
+
+-------------------------------------
+$ git show c82a22c39c	# os primeiros caracteres do nome são o bastante
+			# usualmente
+$ git show HEAD		# a ponta do ramo atual
+$ git show experimental	# a ponta do ramo "experimental"
+-------------------------------------
+
+Todo commit usualmente tem um commit "pai" que aponta para o estado
+anterior do projeto:
+
+-------------------------------------
+$ git show HEAD^  # para ver o pai de HEAD
+$ git show HEAD^^ # para ver o avô de HEAD
+$ git show HEAD~4 # para ver o trisavô de HEAD
+-------------------------------------
+
+Note que commits de unificação podem ter mais de um pai:
+
+-------------------------------------
+$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)
+$ git show HEAD^2 # mostra o segundo pai de HEAD
+-------------------------------------
+
+Você também pode dar aos commits nomes seus; após executar
+
+-------------------------------------
+$ git tag v2.5 1b2e1d63ff
+-------------------------------------
+
+você pode se referir a 1b2e1d63ff pelo nome "v2.5".  Se você pretende
+compartilhar esse nome com outras pessoas (por exemplo, para identificar
+uma versão de lançamento), você deve criar um objeto "tag", e talvez
+assiná-lo; veja linkgit:git-tag[1] para detalhes.
+
+Qualquer comando git que precise conhecer um commit pode receber
+quaisquer desses nomes.  Por exemplo:
+
+-------------------------------------
+$ git diff v2.5 HEAD	 # compara o HEAD atual com v2.5
+$ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado
+			 # em v2.5
+$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de
+			 # trabalho a seu estado em HEAD^
+-------------------------------------
+
+Seja cuidadoso com o último comando: além de perder quaisquer mudanças
+em seu diretório de trabalho, ele também remove todos os commits
+posteriores desse ramo.  Se esse ramo é o único ramo contendo esses
+commits, eles serão perdidos.  Também, não use 'git-reset' num ramo
+publicamente visível de onde outros desenvolvedores puxam, já que vai
+forçar unificações desnecessárias para que outros desenvolvedores limpem
+a história. Se você precisa desfazer mudanças que você empurrou, use
+'git-revert' no lugar.
+
+O comando 'git-grep' pode buscar strings em qualquer versão de seu
+projeto, então
+
+-------------------------------------
+$ git grep "hello" v2.5
+-------------------------------------
+
+procura por todas as ocorreências de "hello" em v2.5.
+
+Se você deixar de fora o nome do commit, 'git-grep' irá procurar
+quaisquer dos arquivos que ele gerencia no diretório corrente.  Então
+
+-------------------------------------
+$ git grep "hello"
+-------------------------------------
+
+é uma forma rápida de buscar somente os arquivos que são rastreados pelo
+git.
+
+Muitos comandos git também recebem um conjunto de commits, o que pode
+ser especificado de um bom número de formas.  Aqui estão alguns exemplos
+com 'git-log':
+
+-------------------------------------
+$ git log v2.5..v2.6            # commits entre v2.5 e v2.6
+$ git log v2.5..                # commits desde v2.5
+$ git log --since="2 weeks ago" # commits das últimas 2 semanas
+$ git log v2.5.. Makefile       # commits desde v2.5 que modificam
+				# Makefile
+-------------------------------------
+
+Você também pode dar ao 'git-log' um "intervalo" de commits onde o
+primeiro não é necessariamente um ancestral do segundo; por exemplo, se
+as pontas dos ramos "stable" e "master" divergiram de um commit
+comum algum tempo atrás, então
+
+-------------------------------------
+$ git log stable..experimental
+-------------------------------------
+
+irá listas os commits feitos no ramo experimental mas não no ramo
+stable, enquanto
+
+-------------------------------------
+$ git log experimental..stable
+-------------------------------------
+
+irá listar a lista de commits feitos no ramo stable mas não no ramo
+experimental.
+
+O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em
+uma lista. Quando a história tem linhas de desenvolvimento que
+divergiram e então foram unificadas novamente, a ordem em que 'git-log'
+apresenta essas mudanças é insignificante.
+
+A maioria dos projetos com múltiplos contribuidores (como o kernel
+linux, ou o git mesmo) tem unificações frequentes, e 'gitk' faz um
+trabalho melhor de visualizar sua história.  Por exemplo,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+permite você navegar em quaisquer commits desde as últimas duas semanas
+de commits que modificaram arquivos sob o diretório "drivers".  (Nota:
+você pode ajustar as fontes do gitk segurando a tecla control enquanto
+pressiona "-" ou "+".)
+
+Finalmente, a maioria dos comandos que recebem nomes de arquivo
+te permitirão opcionalmente preceder qualquer nome de arquivo por um
+commit, para especificar uma versão particular do arquivo:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
+
+Você pode usar 'git-show' para ver tal arquivo:
+
+-------------------------------------
+$ git show v2.5:Makefile
+-------------------------------------
+
+Próximos passos
+----------
+
+Este tutorial deve ser o bastante para operar controle de revisão
+distribuído básico para seus projetos.  No entanto, para entender
+plenamente a profundidade e o poder do git você precisa entender duas
+idéias simples nas quais ele se baseia:
+
+  * A base de objetos é um sistema bem elegante usado para armazenar a
+    história de seu projeto--arquivos, diretórios, e commits.
+
+  * O arquivo de índica é um cache do estado de uma árvore de diretório,
+    usado para criar commits, restaurar diretórios de trabalho, e
+    compreender as várias árvores involvidas em uma unificação.
+
+Parte dois deste tutorial explica a base de objetos, o arquivo de
+índice, e algumas outras coisinhas que você vai precisar pra usar o
+máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].
+
+Se você não quer continuar do jeito certo, algumas outras disgressões
+que podem ser interessantes neste ponto são:
+
+  * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem
+    séries de commits em patches em email, e vice-versa, úteis para
+    projetos como o kernel linux que dependem pesadamente em patches
+    enviados por email.
+
+  * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma
+    forma de rastrear um bug é procurando pela história para encontrar o
+    commit culpado.  Git bisect pode ajudar a executar uma busca binária
+    por esse commit.  Ele é inteligente o bastante para executar uma
+    busca próxima da ótima mesmo no caso de uma história complexa
+    não-linear com muitos ramos unificados.
+
+  * link:everyday.html[GIT diariamente com 20 e tantos comandos]
+
+  * linkgit:gitcvs-migration[7]: Git para usuários de CVS.
+
+Veja Também
+--------
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+linkgit:git-help[1],
+link:everyday.html[git diariamente],
+link:user-manual.html[O Manual do Usuário git]
+
+GIT
+---
+Parte da suite linkgit:git[1].
-- 
1.6.3

Re: [PATCH 2/2] Translate the tutorial to Brazillian Portuguese.

[Junio C Hamano]

Thanks.  Sign-off?

[PATCH] Translate the tutorial to Brazillian Portuguese.

[Thadeu Lima de Souza Cascardo]

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
---
 Documentation/pt/gittutorial.txt |  679 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 679 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/pt/gittutorial.txt

diff --git a/Documentation/pt/gittutorial.txt b/Documentation/pt/gittutorial.txt
new file mode 100644
index 0000000..25bee03
--- /dev/null
+++ b/Documentation/pt/gittutorial.txt
@@ -0,0 +1,679 @@
+gittutorial(7)
+==============
+
+NAME
+----
+gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
+
+Este tutorial explica como importar um novo projeto para o git,
+adicionar mudanças a ele, e compartilhar mudanças com outros
+desenvolvedores.
+
+If, ao invés disso, você está interessado primariamente em usar git para
+obter um projeto, por exemplo, para testar a última versão, você pode
+preferir começar com os primeiros dois capítulos de
+link:user-manual.html[O Manual do Usuário Git].
+
+Primeiro, note que você pode obter documentação para um comando como
+`git log --graph` com:
+
+------------------------------------------------
+$ man git-log
+------------------------------------------------
+
+ou:
+
+------------------------------------------------
+$ git help log
+------------------------------------------------
+
+Com a última forma, você pode usar o visualizador de manual de sua
+escolha; veja linkgit:git-help[1] para maior informação.
+
+É uma boa idéia se introduzir ao git com seu nome e endereço público de
+email antes de fazer qualquer operação. A maneira mais fácil de fazê-lo
+é:
+
+------------------------------------------------
+$ git config --global user.name "Seu Nome Vem Aqui"
+$ git config --global user.email voce@seudominio.exemplo.com
+------------------------------------------------
+
+
+Importando um novo projeto
+-----------------------
+
+Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.
+Você pode colocá-lo sob controle de revisão git como a seguir.
+
+------------------------------------------------
+$ tar xzf project.tar.gz
+$ cd project
+$ git init
+------------------------------------------------
+
+Git irá responder
+
+------------------------------------------------
+Initialized empty Git repository in .git/
+------------------------------------------------
+
+Você agora iniciou seu diretório de trabalho--você deve ter notado um
+novo diretório criado, com o nome de ".git".
+
+A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
+arquivos sob o diretório corrente (note o '.'), com 'git-add':
+
+------------------------------------------------
+$ git add .
+------------------------------------------------
+
+Este instantâneo está agora armazenado em uma área temporária que o git
+chama de "index" ou índice. Você pode permanetemente armazenar o
+conteúdo do índice no repositório com 'git-commit':
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+Isto vai te pedir por uma mensagem de commit. Você agora gravou sua
+primeira versão de seu projeto no git.
+
+Fazendo mudanças
+--------------
+
+Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao
+índice:
+
+------------------------------------------------
+$ git add file1 file2 file3
+------------------------------------------------
+
+Você está agora pronto para fazer o commit. Você pode ver o que está
+para ser gravado usando 'git-diff' com a opção --cached:
+
+------------------------------------------------
+$ git diff --cached
+------------------------------------------------
+
+(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças
+que você tenha feito mas ainda não adicionou ao índice.) Você também
+pode obter um breve sumário da situação com 'git-status':
+
+------------------------------------------------
+$ git status
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#	modified:   file1
+#	modified:   file2
+#	modified:   file3
+#
+------------------------------------------------
+
+Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,
+adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas
+mudanças com:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e,
+então, gravar a nova versão do projeto.
+
+Alternativamente, ao invés de executar 'git-add' antes, você pode usar
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+o que irá automaticamente notar quaisquer arquivos modificados (mas não
+novos), adicioná-los ao índices, e gravar, tudo em um único passo.
+
+Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa
+idéia começar a mensagem com uma simples e curta (menos de 50
+caracteres) linha sumarizando a mudança, seguida de uma linha em branco
+e, então, uma descrição mais detalhada.  Ferramentas que transformam
+commits em email, por exemplo, usam a primeira linha no campo de
+cabeçalho Subject: e o resto no corpo.
+
+Git rastreia conteúdo, não arquivos
+----------------------------
+
+Muitos sistemas de controle de revisão provêem um comando `add` que diz
+ao sistema para começar a rastrear mudanças em um novo arquivo.  O
+comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é
+usado tanto para arquivos novos e arquivos recentemente modificados, e
+em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena
+o conteúdo no índice, pronto para inclusão do próximo commit.
+
+Visualizando história do projeto
+-----------------------
+
+Em qualquer ponto você pode visualizar a história das suas mudanças
+usando
+
+------------------------------------------------
+$ git log
+------------------------------------------------
+
+Se você também quer ver a diferença completa a cada passo, use
+
+------------------------------------------------
+$ git log -p
+------------------------------------------------
+
+Geralmente, uma visão geral da mudança é útil para ter a sensação de
+cada passo
+
+------------------------------------------------
+$ git log --stat --summary
+------------------------------------------------
+
+Gerenciando "branches"/ramos
+-----------------
+
+Um simples repositório git pode manter múltiplos ramos de
+desenvolvimento.  Para criar um novo ramo chamado "experimental", use
+
+------------------------------------------------
+$ git branch experimental
+------------------------------------------------
+
+Se você executar agora
+
+------------------------------------------------
+$ git branch
+------------------------------------------------
+
+você vai obter uma lista de todos os ramos existentes:
+
+------------------------------------------------
+  experimental
+* master
+------------------------------------------------
+
+O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o
+ramo padrão que foi criado pra você automaticamente.  O asterisco marca
+o ramo em que você está atualmente; digite
+
+------------------------------------------------
+$ git checkout experimental
+------------------------------------------------
+
+para mudar para o ramo experimental.  Agora edite um arquivo, grave a
+mudança, e mude de volta para o ramo master:
+
+------------------------------------------------
+(edita arquivo)
+$ git commit -a
+$ git checkout master
+------------------------------------------------
+
+Verifique que a mudança que você fez não está mais visível, já que ela
+foi feita no ramo experimental e você está de volta ao ramo master.
+
+Você pode fazer uma mudança diferente no ramo master:
+
+------------------------------------------------
+(edit file)
+$ git commit -a
+------------------------------------------------
+
+neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em
+cada um.  Para unificar as mudanças feitas no experimental para o
+master, execute
+
+------------------------------------------------
+$ git merge experimental
+------------------------------------------------
+
+Se as mudanças não conflitam, está pronto.  Se existirem conflitos,
+marcadores serão deixados nos arquivos problemáticos exibindo o
+conflito;
+
+------------------------------------------------
+$ git diff
+------------------------------------------------
+
+vai exibir isto.  Após você editar os arquivos para resolver os
+conflitos,
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+irá gravar o resultado da unificação. Finalmente,
+
+------------------------------------------------
+$ gitk
+------------------------------------------------
+
+vai mostrar uma bela representação gráfica da história resultante.
+
+Neste ponto você pode remover seu ramo experimental com
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+Este comando garante que as mudanças no ramo experimental já estão no
+ramo atual.
+
+Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode
+sempre remover o ramo com
+
+-------------------------------------
+$ git branch -D crazy-idea
+-------------------------------------
+
+Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar
+alguma coisa.
+
+Usando git para colaboração
+---------------------------
+
+Suponha que Alice começou um novo projeto com um repositório git em
+/home/alice/project, e que Bob, que tem um diretório home na mesma
+máquina, quer contribuir.
+
+Bob começa com:
+
+------------------------------------------------
+bob$ git clone /home/alice/project myrepo
+------------------------------------------------
+
+Isso cria um novo diretório "myrepo" contendo um clone do repositório de
+Alice.  O clone está no mesmo pé que o projeto original, possuindo sua
+própria cópia da história do projeto original.
+
+Bob então faz algumas mudanças e as grava:
+
+------------------------------------------------
+(editar arquivos)
+bob$ git commit -a
+(repetir conforme necessário)
+------------------------------------------------
+
+Quanto está pronto, ele diz a Alice para puxar as mudanças do
+repositório em /home/bob/myrepo.  Ela o faz com:
+
+------------------------------------------------
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
+------------------------------------------------
+
+Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice.
+Se Alice fez suas próprias mudanças no intervalo, ela, então, pode
+precisar corrigir manualmente quaiquer conflitos.  (Note que o argumento
+"master" no comando acima é, de fato, desnecessário, já que é o padrão.)
+
+O comando "pull" executa, então, duas operações: ele obtém mudanças de
+um ramo remoto, e, então, as unifica no ramo atual.
+
+Note que, em geral, Alice gostaria que suas mudanças locais fossem
+gravadas antes de iniciar este "pull".  Se o trabalho de Bobo conflita
+com o que Alice fez desde que suas histórias se ramificaram, Alice irá
+usar seu diretório de trabalho e o índice para resolver conflitos, e
+mudanças locais existentes irão interferir com o processo de resolução
+de conflitos (git ainda irá realizar a obtenção mas irá se recusar a
+unificar --- Alice terá que se livrar de suas mudanças locais de alguma
+forma e puxar de novo quando isso acontecer).
+
+Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando
+"fetch"; isto permite Alice inspecionar o que Bob fez, usando um símbolo
+especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa
+que vale puxar, assim:
+
+------------------------------------------------
+alice$ git fetch /home/bob/myrepo master
+alice$ git log -p HEAD..FETCH_HEAD
+------------------------------------------------
+
+Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.
+A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é
+alcançável de FETCH_HEAD mas exclua tudo que é alcançável de HEAD. Alcie
+já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob tem
+em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.
+
+Se Alice quer visualizar o que Bob fez desde que suas história
+ramificaram, ela pode disparar o seguinte comando:
+
+------------------------------------------------
+$ gitk HEAD..FETCH_HEAD
+------------------------------------------------
+
+Isto usar a mesma notação de intervaldo que vimos antes com 'git log'.
+
+Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela
+pode usar a forma com três pontos ao invés da forma com dois pontos:
+
+------------------------------------------------
+$ gitk HEAD...FETCH_HEAD
+------------------------------------------------
+
+Isto significa "mostre tudo que é alcançavel de qualquer um, mas exclua
+tudo que é alcançavel a partir de ambos".
+This means "show everything that is reachable from either one, but
+exclude anything that is reachable from both of them".
+
+Por favor, note que essas notações de intervalo podem ser usadas tanto
+com gitk quanto com "git log".
+
+Apoós inspecionar o que Bob fez, se não há nada urgente, Alice pode
+decidir continuar trabalhando sem puxar de Bob.  Se a história de Bob
+tem alguma coisa que Alice precisa imediatamente, Alice pode optar por
+separar seu trabalho em progresso primeiro, fazer um "pull", e, então,
+finalmente, retomar seu trabalho em progresso em cima da história
+resultante.
+
+Quanto você está trabalhando em um pequeno grupo unido, não é incomum
+interagir com o mesmo repositório várias e várias vezes.  Definindo um
+repositório remoto antes de tudo, você pode fazê-lo mais facilmente:
+
+------------------------------------------------
+alice$ git remote add bob /home/bob/myrepo
+------------------------------------------------
+
+Com isso, Alice pode executar a primeira parte da operação "pull" usando
+o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,
+usando:
+
+-------------------------------------
+alice$ git fetch bob
+-------------------------------------
+
+Diferente da forma longa, quando Alice obteve de Bob usando um
+repositório remoto antes definido com 'git-remote', o que foi obtido é
+armazenado um ramo remoto, neste caso `bob/master`.  Então, após isso:
+
+-------------------------------------
+alice$ git log -p master..bob/master
+-------------------------------------
+
+mostra uma lista de todas as mudanças que Bob fez desde que ramificou do
+ramo master de Alice.
+
+Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:
+
+-------------------------------------
+alice$ git merge bob/master
+-------------------------------------
+
+Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,
+assim:
+
+-------------------------------------
+alice$ git pull . remotes/bob/master
+-------------------------------------
+
+Note que 'git pull' sempre unifica ao ramo atual, independente do que
+mais foi dado na linha de comando.
+
+Depois, Bob pode atualizar seu repositório com as últimas mudanças de
+Alice, usando
+
+-------------------------------------
+bob$ git pull
+-------------------------------------
+
+Note que ele não precisa dar o caminho do repositório de Alice; quando
+Bob clonou seu repositório, o git armazenou a localização de seu
+repositório na configuração do repositório, e essa localização é usada
+para puxar:
+
+-------------------------------------
+bob$ git config --get remote.origin.url
+/home/alice/project
+-------------------------------------
+
+(A configuração completa criada por 'git-clone' é visível usando `git
+config -l`, e a página de manual linkgit:git-config[1] explica o
+significado de cada opção.)
+
+Git também mantém uma cópia limpa do ramo master de Alice sob o nome
+"origin/master":
+
+-------------------------------------
+bob$ git branch -r
+  origin/master
+-------------------------------------
+
+Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode
+executar clones e puxar usando o protocolo ssh:
+
+-------------------------------------
+bob$ git clone alice.org:/home/alice/project myrepo
+-------------------------------------
+
+Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou
+http; veja linkgit:git-pull[1] para detalhes.
+
+Git pode também ser usado em um modo parecido com CVS, com um
+repositório central para o qual que vários usuários empurram
+modificações; veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].
+
+Explorando história
+-----------------
+
+A história no git é representada como uma série de commits
+interrelacionados.  Nós já vimos que o comando 'git-log' pode listar
+esses commits. Note que a primeira linha de cama entrada no log também
+dá o nome para o commit:
+
+-------------------------------------
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date:   Tue May 16 17:18:22 2006 -0700
+
+    merge-base: Clarify the comments on post processing.
+-------------------------------------
+
+Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este
+commit.
+
+-------------------------------------
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+-------------------------------------
+
+Mas há outras formas de se referir a commits.  Você pode usar qualquer
+parte inicial do nome que seja longo o bastante para unicamente
+identificar o commit:
+
+-------------------------------------
+$ git show c82a22c39c	# os primeiros caracteres do nome são o bastante
+			# usualmente
+$ git show HEAD		# a ponta do ramo atual
+$ git show experimental	# a ponta do ramo "experimental"
+-------------------------------------
+
+Todo commit usualmente tem um commit "pai" que aponta para o estado
+anterior do projeto:
+
+-------------------------------------
+$ git show HEAD^  # para ver o pai de HEAD
+$ git show HEAD^^ # para ver o avô de HEAD
+$ git show HEAD~4 # para ver o trisavô de HEAD
+-------------------------------------
+
+Note que commits de unificação podem ter mais de um pai:
+
+-------------------------------------
+$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)
+$ git show HEAD^2 # mostra o segundo pai de HEAD
+-------------------------------------
+
+Você também pode dar aos commits nomes seus; após executar
+
+-------------------------------------
+$ git tag v2.5 1b2e1d63ff
+-------------------------------------
+
+você pode se referir a 1b2e1d63ff pelo nome "v2.5".  Se você pretende
+compartilhar esse nome com outras pessoas (por exemplo, para identificar
+uma versão de lançamento), você deve criar um objeto "tag", e talvez
+assiná-lo; veja linkgit:git-tag[1] para detalhes.
+
+Qualquer comando git que precise conhecer um commit pode receber
+quaisquer desses nomes.  Por exemplo:
+
+-------------------------------------
+$ git diff v2.5 HEAD	 # compara o HEAD atual com v2.5
+$ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado
+			 # em v2.5
+$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de
+			 # trabalho a seu estado em HEAD^
+-------------------------------------
+
+Seja cuidadoso com o último comando: além de perder quaisquer mudanças
+em seu diretório de trabalho, ele também remove todos os commits
+posteriores desse ramo.  Se esse ramo é o único ramo contendo esses
+commits, eles serão perdidos.  Também, não use 'git-reset' num ramo
+publicamente visível de onde outros desenvolvedores puxam, já que vai
+forçar unificações desnecessárias para que outros desenvolvedores limpem
+a história. Se você precisa desfazer mudanças que você empurrou, use
+'git-revert' no lugar.
+
+O comando 'git-grep' pode buscar strings em qualquer versão de seu
+projeto, então
+
+-------------------------------------
+$ git grep "hello" v2.5
+-------------------------------------
+
+procura por todas as ocorreências de "hello" em v2.5.
+
+Se você deixar de fora o nome do commit, 'git-grep' irá procurar
+quaisquer dos arquivos que ele gerencia no diretório corrente.  Então
+
+-------------------------------------
+$ git grep "hello"
+-------------------------------------
+
+é uma forma rápida de buscar somente os arquivos que são rastreados pelo
+git.
+
+Muitos comandos git também recebem um conjunto de commits, o que pode
+ser especificado de um bom número de formas.  Aqui estão alguns exemplos
+com 'git-log':
+
+-------------------------------------
+$ git log v2.5..v2.6            # commits entre v2.5 e v2.6
+$ git log v2.5..                # commits desde v2.5
+$ git log --since="2 weeks ago" # commits das últimas 2 semanas
+$ git log v2.5.. Makefile       # commits desde v2.5 que modificam
+				# Makefile
+-------------------------------------
+
+Você também pode dar ao 'git-log' um "intervalo" de commits onde o
+primeiro não é necessariamente um ancestral do segundo; por exemplo, se
+as pontas dos ramos "stable" e "master" divergiram de um commit
+comum algum tempo atrás, então
+
+-------------------------------------
+$ git log stable..experimental
+-------------------------------------
+
+irá listas os commits feitos no ramo experimental mas não no ramo
+stable, enquanto
+
+-------------------------------------
+$ git log experimental..stable
+-------------------------------------
+
+irá listar a lista de commits feitos no ramo stable mas não no ramo
+experimental.
+
+O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em
+uma lista. Quando a história tem linhas de desenvolvimento que
+divergiram e então foram unificadas novamente, a ordem em que 'git-log'
+apresenta essas mudanças é insignificante.
+
+A maioria dos projetos com múltiplos contribuidores (como o kernel
+linux, ou o git mesmo) tem unificações frequentes, e 'gitk' faz um
+trabalho melhor de visualizar sua história.  Por exemplo,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+permite você navegar em quaisquer commits desde as últimas duas semanas
+de commits que modificaram arquivos sob o diretório "drivers".  (Nota:
+você pode ajustar as fontes do gitk segurando a tecla control enquanto
+pressiona "-" ou "+".)
+
+Finalmente, a maioria dos comandos que recebem nomes de arquivo
+te permitirão opcionalmente preceder qualquer nome de arquivo por um
+commit, para especificar uma versão particular do arquivo:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
+
+Você pode usar 'git-show' para ver tal arquivo:
+
+-------------------------------------
+$ git show v2.5:Makefile
+-------------------------------------
+
+Próximos passos
+----------
+
+Este tutorial deve ser o bastante para operar controle de revisão
+distribuído básico para seus projetos.  No entanto, para entender
+plenamente a profundidade e o poder do git você precisa entender duas
+idéias simples nas quais ele se baseia:
+
+  * A base de objetos é um sistema bem elegante usado para armazenar a
+    história de seu projeto--arquivos, diretórios, e commits.
+
+  * O arquivo de índica é um cache do estado de uma árvore de diretório,
+    usado para criar commits, restaurar diretórios de trabalho, e
+    compreender as várias árvores involvidas em uma unificação.
+
+Parte dois deste tutorial explica a base de objetos, o arquivo de
+índice, e algumas outras coisinhas que você vai precisar pra usar o
+máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].
+
+Se você não quer continuar do jeito certo, algumas outras disgressões
+que podem ser interessantes neste ponto são:
+
+  * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem
+    séries de commits em patches em email, e vice-versa, úteis para
+    projetos como o kernel linux que dependem pesadamente em patches
+    enviados por email.
+
+  * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma
+    forma de rastrear um bug é procurando pela história para encontrar o
+    commit culpado.  Git bisect pode ajudar a executar uma busca binária
+    por esse commit.  Ele é inteligente o bastante para executar uma
+    busca próxima da ótima mesmo no caso de uma história complexa
+    não-linear com muitos ramos unificados.
+
+  * link:everyday.html[GIT diariamente com 20 e tantos comandos]
+
+  * linkgit:gitcvs-migration[7]: Git para usuários de CVS.
+
+Veja Também
+--------
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+linkgit:git-help[1],
+link:everyday.html[git diariamente],
+link:user-manual.html[O Manual do Usuário git]
+
+GIT
+---
+Parte da suite linkgit:git[1].
-- 
1.6.3

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[Junio C Hamano]

Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:

> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>

Thanks.

> +Você também pode dar ao 'git-log' um "intervalo" de commits onde o
> +primeiro não é necessariamente um ancestral do segundo; por exemplo, se
> +as pontas dos ramos "stable" e "master" divergiram de um commit
> +comum algum tempo atrás, então
> +
> +-------------------------------------
> +$ git log stable..experimental
> +-------------------------------------
> +
> +irá listas os commits feitos no ramo experimental mas não no ramo
> +stable, enquanto
> +
> +-------------------------------------
> +$ git log experimental..stable
> +-------------------------------------
> +
> +irá listar a lista de commits feitos no ramo stable mas não no ramo
> +experimental.
> +

I think you would want to update this part to match what you did in your
[PATCH 1/2 v2].

    By the way, I think your MUA sent quoted-printable UTF-8 but somewhere
    between your keyboard and vger the message was marked with content-type
    charset=ISO-8859-1); I fixed it up when quoting the above.

I am somewhat worried about the way how this translation will be
maintained to keep in sync with the authoritative English version.
Narita-san (CC'ed) who translated the document to Japanese did this:

    gittutorial(7)
    ==============
    // = gittutorial(7)

    NAME
    ----
    // == NAME
    gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)
    // gittutorial - git チュートリアル (バージョン 1.5.1 以降用)

and the idea seems that without // (comments in AsciiDoc markup) it
matches the English copy, and after passing sed -ne 's|^// ||p' it yields
Japanese version.  Narita-san's translation can be seen at

    http://github.com/yasuaki/git-manual-jp.git/Documentation

if anybody is interested.

With this format, merging upstream changes may not work as smoothly as it
could be, but at least you can check which part of your translation is
based on a stale copy with something like this arrangement.

I am wondering if it would be a good idea to extend Narita-san's scheme so
that we can keep a single source, perhaps like:

    = gittutorial(7)
    // ja = gittutorial(7)
    // pt = gittutorial(7)
    == NAME
    // ja = NAME
    // pt = NAME
    gittutorial - A tutorial introduction to git (for version 1.5.1 or ...
    // ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
    // pt gittutorial - Um tutorial de introdução ao git (para versão 1....

Then whenever somebody makes a change to the English version, he can and
should also mark the corresponding translated versions "stale", so that it
is easier to spot by translators.

    diff --git a/gittutorial.txt b/gittutorial.txt
    index 4478300..02d67d3 100644
    --- a/gittutorial.txt
    +++ b/gittutorial.txt
    @@ -4,7 +4,6 @@
     == NAME
     // ja = NAME
     // pt = NAME
    -gittutorial - A tutorial introduction to git (for version 1.5.1 or n...
    -// ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
    -// pt gittutorial - Um tutorial de introdução ao git (para versão 1....
    -
    +gittutorial - A tutorial introduction to git (for version 1.6.3 or n...
    +// **stale** ja gittutorial - git チュートリアル (バージョン 1.5.1 ...
    +// **stale** pt gittutorial - Um tutorial de introdução ao git (par...

As long as all the translations use the same encoding (I think UTF-8 is
the only practical choice for this), keeping translated strings in a
single file would be doable.

I however am not sure how practical it would be to force people to look at
the *.txt version of document, only 1/n lines of which is now readable by
him (if you are like a typical American who understands only English ;-).

Thoughts?

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 4652 bytes --]

On Mon, Jun 29, 2009 at 09:08:00AM -0700, Junio C Hamano wrote:
> Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:
> 
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> 
> Thanks.
> 
> > +Você também pode dar ao 'git-log' um "intervalo" de commits onde o
> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se
> > +as pontas dos ramos "stable" e "master" divergiram de um commit
> > +comum algum tempo atrás, então
> > +
> > +-------------------------------------
> > +$ git log stable..experimental
> > +-------------------------------------
> > +
> > +irá listas os commits feitos no ramo experimental mas não no ramo
> > +stable, enquanto
> > +
> > +-------------------------------------
> > +$ git log experimental..stable
> > +-------------------------------------
> > +
> > +irá listar a lista de commits feitos no ramo stable mas não no ramo
> > +experimental.
> > +
> 
> I think you would want to update this part to match what you did in your
> [PATCH 1/2 v2].
> 

Well remembered. Thanks.

>     By the way, I think your MUA sent quoted-printable UTF-8 but somewhere
>     between your keyboard and vger the message was marked with content-type
>     charset=ISO-8859-1); I fixed it up when quoting the above.
> 

I am going to take a look at it.

> I am somewhat worried about the way how this translation will be
> maintained to keep in sync with the authoritative English version.
> Narita-san (CC'ed) who translated the document to Japanese did this:
> 
>     gittutorial(7)
>     ==============
>     // = gittutorial(7)
> 
>     NAME
>     ----
>     // == NAME
>     gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)
>     // gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
> 
> and the idea seems that without // (comments in AsciiDoc markup) it
> matches the English copy, and after passing sed -ne 's|^// ||p' it yields
> Japanese version.  Narita-san's translation can be seen at
> 
>     http://github.com/yasuaki/git-manual-jp.git/Documentation
> 
> if anybody is interested.
> 
> With this format, merging upstream changes may not work as smoothly as it
> could be, but at least you can check which part of your translation is
> based on a stale copy with something like this arrangement.
> 
> I am wondering if it would be a good idea to extend Narita-san's scheme so
> that we can keep a single source, perhaps like:
> 
>     = gittutorial(7)
>     // ja = gittutorial(7)
>     // pt = gittutorial(7)
>     == NAME
>     // ja = NAME
>     // pt = NAME
>     gittutorial - A tutorial introduction to git (for version 1.5.1 or ...
>     // ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
>     // pt gittutorial - Um tutorial de introdução ao git (para versão 1....
> 
> Then whenever somebody makes a change to the English version, he can and
> should also mark the corresponding translated versions "stale", so that it
> is easier to spot by translators.
> 
>     diff --git a/gittutorial.txt b/gittutorial.txt
>     index 4478300..02d67d3 100644
>     --- a/gittutorial.txt
>     +++ b/gittutorial.txt
>     @@ -4,7 +4,6 @@
>      == NAME
>      // ja = NAME
>      // pt = NAME
>     -gittutorial - A tutorial introduction to git (for version 1.5.1 or n...
>     -// ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
>     -// pt gittutorial - Um tutorial de introdução ao git (para versão 1....
>     -
>     +gittutorial - A tutorial introduction to git (for version 1.6.3 or n...
>     +// **stale** ja gittutorial - git チュートリアル (バージョン 1.5.1 ...
>     +// **stale** pt gittutorial - Um tutorial de introdução ao git (par...
> 
> As long as all the translations use the same encoding (I think UTF-8 is
> the only practical choice for this), keeping translated strings in a
> single file would be doable.
> 
> I however am not sure how practical it would be to force people to look at
> the *.txt version of document, only 1/n lines of which is now readable by
> him (if you are like a typical American who understands only English ;-).
> 
> Thoughts?

I think that using something like po would be better. There are tools
that can extract and update the template messages from many differente
sources. Adapting them to produce a template file from gittutorial.txt
would allow translators to verify how stale their translations are and
much smoother merges. How about that?

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:

> > +Você também pode dar ao 'git-log' um "intervalo" de commits onde o
> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se
> > +as pontas dos ramos "stable" e "master" divergiram de um commit
> > +comum algum tempo atrás, então
> > +
> > +-------------------------------------
> > +$ git log stable..experimental
> > +-------------------------------------
 
> I am somewhat worried about the way how this translation will be
> maintained to keep in sync with the authoritative English version.
> Narita-san (CC'ed) who translated the document to Japanese did this:
> 
>     gittutorial(7)
>     ==============
>     // = gittutorial(7)
> 
>     NAME
>     ----
>     // == NAME
>     gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)
>     // gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
> 
> and the idea seems that without // (comments in AsciiDoc markup) it
> matches the English copy, and after passing sed -ne 's|^// ||p' it yields
> Japanese version.  Narita-san's translation can be seen at
> 
>     http://github.com/yasuaki/git-manual-jp.git/Documentation
> 
> if anybody is interested.
> 
> With this format, merging upstream changes may not work as smoothly as it
> could be, but at least you can check which part of your translation is
> based on a stale copy with something like this arrangement.
> 
> I am wondering if it would be a good idea to extend Narita-san's scheme so
> that we can keep a single source, perhaps like:
> 
>     = gittutorial(7)
>     // ja = gittutorial(7)
>     // pt = gittutorial(7)
>     == NAME
>     // ja = NAME
>     // pt = NAME
>     gittutorial - A tutorial introduction to git (for version 1.5.1 or ...
>     // ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)
>     // pt gittutorial - Um tutorial de introdução ao git (para versão 1....
> 
> Then whenever somebody makes a change to the English version, he can and
> should also mark the corresponding translated versions "stale", so that it
> is easier to spot by translators.

[...]
> I however am not sure how practical it would be to force people to look at
> the *.txt version of document, only 1/n lines of which is now readable by
> him (if you are like a typical American who understands only English ;-).
> 
> Thoughts?

Somebody here (or on #git channel) pointed that there is po4a[1-4]
project using gettext to translate documentation.

[1] http://po4a.alioth.debian.org/
[2] https://launchpad.net/po4a
[3] http://freshmeat.net/projects/po4a
[4] http://www.ohloh.net/p/po4a
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[Junio C Hamano]

Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:

> On Mon, Jun 29, 2009 at 09:08:00AM -0700, Junio C Hamano wrote:
>> Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:
>> 
>> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
>> 
>> Thanks.
>> 
>> > +Você também pode dar ao 'git-log' um "intervalo" de commits onde o
>> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se
>> > +as pontas dos ramos "stable" e "master" divergiram de um commit
>> > +comum algum tempo atrás, então
>> > +
>> > +-------------------------------------
>> > +$ git log stable..experimental
>> > +-------------------------------------
>> > +
>> > +irá listas os commits feitos no ramo experimental mas não no ramo
>> > +stable, enquanto
>> > +
>> > +-------------------------------------
>> > +$ git log experimental..stable
>> > +-------------------------------------
>> > +
>> > +irá listar a lista de commits feitos no ramo stable mas não no ramo
>> > +experimental.
>> > +
>> 
>> I think you would want to update this part to match what you did in your
>> [PATCH 1/2 v2].
>
> Well remembered. Thanks.

As I do not speak the language, even though I can guess that a straight
replacement "s/experimental/master/g" would be enough for the above quoted
part (including the body text), I do not feel comfortable enough to update
these myself.  Please send in a replacement [PATCH 2/2 v2].

>> I however am not sure how practical it would be to force people to look at
>> the *.txt version of document, only 1/n lines of which is now readable by
>> him (if you are like a typical American who understands only English ;-).
>> 
>> Thoughts?
>
> I think that using something like po would be better. There are tools
> that can extract and update the template messages from many differente
> sources. Adapting them to produce a template file from gittutorial.txt
> would allow translators to verify how stale their translations are and
> much smoother merges. How about that?

After thinking about it a bit more, I think I would prefer something that
keeps translation sources separate from the original text.  That way, I
have a lot less chance of having to deal with merge/patch conflicts.

Your patch adds Documentation/pt/ hierarchy, but I noticed that the kernel
folks seem to use Documentation/{ja_JP,ko_KR,zh_CN}/.  I do not think it
would make much difference for Japanese language between ja vs ja_JP, but
for many languages used in different geographic areas, such an arrangement
would make a lot more sense.  As your patch identified itself as a
translation to "Brasilian Portuguese", I am imagining that it would be
sufficiently different to merit the distinction from Old-world Portuguese.
Perhaps your patch should be made to Documentation/pt_BR instead?

As to the choice of the tool, from a quick superficial glance, po4a could
be a reasonable choice, but I do not know how mature and/or widely used it
is, or if there are better alternatives.  http://po4a.alioth.debian.org/
says it does support AsciiDoc.

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[André Goddard Rosa]

>> I think that using something like po would be better. There are tools
>> that can extract and update the template messages from many differente
>> sources. Adapting them to produce a template file from gittutorial.txt
>> would allow translators to verify how stale their translations are and
>> much smoother merges. How about that?
>
> After thinking about it a bit more, I think I would prefer something that
> keeps translation sources separate from the original text.  That way, I
> have a lot less chance of having to deal with merge/patch conflicts.
>
> Your patch adds Documentation/pt/ hierarchy, but I noticed that the kernel
> folks seem to use Documentation/{ja_JP,ko_KR,zh_CN}/.  I do not think it
> would make much difference for Japanese language between ja vs ja_JP, but
> for many languages used in different geographic areas, such an arrangement
> would make a lot more sense.  As your patch identified itself as a
> translation to "Brasilian Portuguese", I am imagining that it would be
> sufficiently different to merit the distinction from Old-world Portuguese.
> Perhaps your patch should be made to Documentation/pt_BR instead?
>
> As to the choice of the tool, from a quick superficial glance, po4a could
> be a reasonable choice, but I do not know how mature and/or widely used it
> is, or if there are better alternatives.  http://po4a.alioth.debian.org/
> says it does support AsciiDoc.

git gui uses 'po' at http://repo.or.cz/w/git-gui/git-gui-i18n.git to
handle all translations, including Brazilian Portuguese.

In the meantime, I've made some translation improvements over Thadeu's
translation work, fixing some typos overall. I'll send it as a
separate patch.

@Thadeu: would you please double check it and perhaps add your Acked-by?

Thanks,
Andre

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Thu, Jul 30, 2009 at 12:26:14AM -0300, André Goddard Rosa wrote:
> git gui uses 'po' at http://repo.or.cz/w/git-gui/git-gui-i18n.git to
> handle all translations, including Brazilian Portuguese.
> 

But do they use it for Documentation? It doesn't seem so. po4a seems to
be a reasonable choice, which, in the end, means po too. But it would be
interesting to gather others experiences in keeping Documentation
translations updated, not only software strings.

> In the meantime, I've made some translation improvements over Thadeu's
> translation work, fixing some typos overall. I'll send it as a
> separate patch.
> 
> @Thadeu: would you please double check it and perhaps add your Acked-by?
> 

It seems OK, but for three fixes as I've sent before. Would you mind
re-sending them?

> Thanks,
> Andre

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Translate the tutorial to Brazillian Portuguese.

[André Goddard Rosa]

On 7/30/09, Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> wrote:
> On Thu, Jul 30, 2009 at 12:26:14AM -0300, André Goddard Rosa wrote:
>> git gui uses 'po' at http://repo.or.cz/w/git-gui/git-gui-i18n.git to
>> handle all translations, including Brazilian Portuguese.
>>
>
> But do they use it for Documentation? It doesn't seem so. po4a seems to
> be a reasonable choice, which, in the end, means po too. But it would be
> interesting to gather others experiences in keeping Documentation
> translations updated, not only software strings.

Sure, that's what po4a is meant for.

>> @Thadeu: would you please double check it and perhaps add your Acked-by?
>>
>
> It seems OK, but for three fixes as I've sent before. Would you mind
> re-sending them?

I've sent it including the contributions/fixes from you and Carlos.

Thanks,
Andre