{"thread":{"id":"19963","subject":"[PATCH 2/2] Translate the tutorial to Brazillian Portuguese.","startedAt":"2009-06-29T14:05:58Z","lastAt":"2009-07-30T17:42:25Z","messageCount":10,"participants":["Thadeu Lima de Souza Cascardo","Junio C Hamano","Jakub Narebski","André Goddard Rosa"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"117160","messageId":"1246284358-26491-1-git-send-email-cascardo@holoscopio.com","threadId":"19963","inReplyTo":null,"subject":"[PATCH 2/2] Translate the tutorial to Brazillian Portuguese.","fromName":"Thadeu Lima de Souza Cascardo","fromEmail":"cascardo@holoscopio.com","sentAt":"2009-06-29T14:05:58Z","receivedAt":"2009-06-29T14:05:58Z","isPatch":true,"sender":{"key":"cascardo@holoscopio.com","avatar":null},"body":"---\n Documentation/pt/gittutorial.txt |  679 ++++++++++++++++++++++++++++++++++++++\n 1 files changed, 679 insertions(+), 0 deletions(-)\n create mode 100644 Documentation/pt/gittutorial.txt\n\ndiff --git a/Documentation/pt/gittutorial.txt b/Documentation/pt/gittutorial.txt\nnew file mode 100644\nindex 0000000..25bee03\n--- /dev/null\n+++ b/Documentation/pt/gittutorial.txt\n@@ -0,0 +1,679 @@\n+gittutorial(7)\n+==============\n+\n+NAME\n+----\n+gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)\n+\n+SYNOPSIS\n+--------\n+git *\n+\n+DESCRIPTION\n+-----------\n+\n+Este tutorial explica como importar um novo projeto para o git,\n+adicionar mudanças a ele, e compartilhar mudanças com outros\n+desenvolvedores.\n+\n+If, ao invés disso, você está interessado primariamente em usar git para\n+obter um projeto, por exemplo, para testar a última versão, você pode\n+preferir começar com os primeiros dois capítulos de\n+link:user-manual.html[O Manual do Usuário Git].\n+\n+Primeiro, note que você pode obter documentação para um comando como\n+`git log --graph` com:\n+\n+------------------------------------------------\n+$ man git-log\n+------------------------------------------------\n+\n+ou:\n+\n+------------------------------------------------\n+$ git help log\n+------------------------------------------------\n+\n+Com a última forma, você pode usar o visualizador de manual de sua\n+escolha; veja linkgit:git-help[1] para maior informação.\n+\n+É uma boa idéia se introduzir ao git com seu nome e endereço público de\n+email antes de fazer qualquer operação. A maneira mais fácil de fazê-lo\n+é:\n+\n+------------------------------------------------\n+$ git config --global user.name \"Seu Nome Vem Aqui\"\n+$ git config --global user.email voce@seudominio.exemplo.com\n+------------------------------------------------\n+\n+\n+Importando um novo projeto\n+-----------------------\n+\n+Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.\n+Você pode colocá-lo sob controle de revisão git como a seguir.\n+\n+------------------------------------------------\n+$ tar xzf project.tar.gz\n+$ cd project\n+$ git init\n+------------------------------------------------\n+\n+Git irá responder\n+\n+------------------------------------------------\n+Initialized empty Git repository in .git/\n+------------------------------------------------\n+\n+Você agora iniciou seu diretório de trabalho--você deve ter notado um\n+novo diretório criado, com o nome de \".git\".\n+\n+A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os\n+arquivos sob o diretório corrente (note o '.'), com 'git-add':\n+\n+------------------------------------------------\n+$ git add .\n+------------------------------------------------\n+\n+Este instantâneo está agora armazenado em uma área temporária que o git\n+chama de \"index\" ou índice. Você pode permanetemente armazenar o\n+conteúdo do índice no repositório com 'git-commit':\n+\n+------------------------------------------------\n+$ git commit\n+------------------------------------------------\n+\n+Isto vai te pedir por uma mensagem de commit. Você agora gravou sua\n+primeira versão de seu projeto no git.\n+\n+Fazendo mudanças\n+--------------\n+\n+Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao\n+índice:\n+\n+------------------------------------------------\n+$ git add file1 file2 file3\n+------------------------------------------------\n+\n+Você está agora pronto para fazer o commit. Você pode ver o que está\n+para ser gravado usando 'git-diff' com a opção --cached:\n+\n+------------------------------------------------\n+$ git diff --cached\n+------------------------------------------------\n+\n+(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças\n+que você tenha feito mas ainda não adicionou ao índice.) Você também\n+pode obter um breve sumário da situação com 'git-status':\n+\n+------------------------------------------------\n+$ git status\n+# On branch master\n+# Changes to be committed:\n+#   (use \"git reset HEAD <file>...\" to unstage)\n+#\n+#\tmodified:   file1\n+#\tmodified:   file2\n+#\tmodified:   file3\n+#\n+------------------------------------------------\n+\n+Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,\n+adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas\n+mudanças com:\n+\n+------------------------------------------------\n+$ git commit\n+------------------------------------------------\n+\n+Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e,\n+então, gravar a nova versão do projeto.\n+\n+Alternativamente, ao invés de executar 'git-add' antes, você pode usar\n+\n+------------------------------------------------\n+$ git commit -a\n+------------------------------------------------\n+\n+o que irá automaticamente notar quaisquer arquivos modificados (mas não\n+novos), adicioná-los ao índices, e gravar, tudo em um único passo.\n+\n+Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa\n+idéia começar a mensagem com uma simples e curta (menos de 50\n+caracteres) linha sumarizando a mudança, seguida de uma linha em branco\n+e, então, uma descrição mais detalhada.  Ferramentas que transformam\n+commits em email, por exemplo, usam a primeira linha no campo de\n+cabeçalho Subject: e o resto no corpo.\n+\n+Git rastreia conteúdo, não arquivos\n+----------------------------\n+\n+Muitos sistemas de controle de revisão provêem um comando `add` que diz\n+ao sistema para começar a rastrear mudanças em um novo arquivo.  O\n+comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é\n+usado tanto para arquivos novos e arquivos recentemente modificados, e\n+em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena\n+o conteúdo no índice, pronto para inclusão do próximo commit.\n+\n+Visualizando história do projeto\n+-----------------------\n+\n+Em qualquer ponto você pode visualizar a história das suas mudanças\n+usando\n+\n+------------------------------------------------\n+$ git log\n+------------------------------------------------\n+\n+Se você também quer ver a diferença completa a cada passo, use\n+\n+------------------------------------------------\n+$ git log -p\n+------------------------------------------------\n+\n+Geralmente, uma visão geral da mudança é útil para ter a sensação de\n+cada passo\n+\n+------------------------------------------------\n+$ git log --stat --summary\n+------------------------------------------------\n+\n+Gerenciando \"branches\"/ramos\n+-----------------\n+\n+Um simples repositório git pode manter múltiplos ramos de\n+desenvolvimento.  Para criar um novo ramo chamado \"experimental\", use\n+\n+------------------------------------------------\n+$ git branch experimental\n+------------------------------------------------\n+\n+Se você executar agora\n+\n+------------------------------------------------\n+$ git branch\n+------------------------------------------------\n+\n+você vai obter uma lista de todos os ramos existentes:\n+\n+------------------------------------------------\n+  experimental\n+* master\n+------------------------------------------------\n+\n+O ramo \"experimental\" é o que você acaba de criar, e o ramo \"master\" é o\n+ramo padrão que foi criado pra você automaticamente.  O asterisco marca\n+o ramo em que você está atualmente; digite\n+\n+------------------------------------------------\n+$ git checkout experimental\n+------------------------------------------------\n+\n+para mudar para o ramo experimental.  Agora edite um arquivo, grave a\n+mudança, e mude de volta para o ramo master:\n+\n+------------------------------------------------\n+(edita arquivo)\n+$ git commit -a\n+$ git checkout master\n+------------------------------------------------\n+\n+Verifique que a mudança que você fez não está mais visível, já que ela\n+foi feita no ramo experimental e você está de volta ao ramo master.\n+\n+Você pode fazer uma mudança diferente no ramo master:\n+\n+------------------------------------------------\n+(edit file)\n+$ git commit -a\n+------------------------------------------------\n+\n+neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em\n+cada um.  Para unificar as mudanças feitas no experimental para o\n+master, execute\n+\n+------------------------------------------------\n+$ git merge experimental\n+------------------------------------------------\n+\n+Se as mudanças não conflitam, está pronto.  Se existirem conflitos,\n+marcadores serão deixados nos arquivos problemáticos exibindo o\n+conflito;\n+\n+------------------------------------------------\n+$ git diff\n+------------------------------------------------\n+\n+vai exibir isto.  Após você editar os arquivos para resolver os\n+conflitos,\n+\n+------------------------------------------------\n+$ git commit -a\n+------------------------------------------------\n+\n+irá gravar o resultado da unificação. Finalmente,\n+\n+------------------------------------------------\n+$ gitk\n+------------------------------------------------\n+\n+vai mostrar uma bela representação gráfica da história resultante.\n+\n+Neste ponto você pode remover seu ramo experimental com\n+\n+------------------------------------------------\n+$ git branch -d experimental\n+------------------------------------------------\n+\n+Este comando garante que as mudanças no ramo experimental já estão no\n+ramo atual.\n+\n+Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode\n+sempre remover o ramo com\n+\n+-------------------------------------\n+$ git branch -D crazy-idea\n+-------------------------------------\n+\n+Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar\n+alguma coisa.\n+\n+Usando git para colaboração\n+---------------------------\n+\n+Suponha que Alice começou um novo projeto com um repositório git em\n+/home/alice/project, e que Bob, que tem um diretório home na mesma\n+máquina, quer contribuir.\n+\n+Bob começa com:\n+\n+------------------------------------------------\n+bob$ git clone /home/alice/project myrepo\n+------------------------------------------------\n+\n+Isso cria um novo diretório \"myrepo\" contendo um clone do repositório de\n+Alice.  O clone está no mesmo pé que o projeto original, possuindo sua\n+própria cópia da história do projeto original.\n+\n+Bob então faz algumas mudanças e as grava:\n+\n+------------------------------------------------\n+(editar arquivos)\n+bob$ git commit -a\n+(repetir conforme necessário)\n+------------------------------------------------\n+\n+Quanto está pronto, ele diz a Alice para puxar as mudanças do\n+repositório em /home/bob/myrepo.  Ela o faz com:\n+\n+------------------------------------------------\n+alice$ cd /home/alice/project\n+alice$ git pull /home/bob/myrepo master\n+------------------------------------------------\n+\n+Isto unifica as mudanças do ramo \"master\" do Bob ao ramo atual de Alice.\n+Se Alice fez suas próprias mudanças no intervalo, ela, então, pode\n+precisar corrigir manualmente quaiquer conflitos.  (Note que o argumento\n+\"master\" no comando acima é, de fato, desnecessário, já que é o padrão.)\n+\n+O comando \"pull\" executa, então, duas operações: ele obtém mudanças de\n+um ramo remoto, e, então, as unifica no ramo atual.\n+\n+Note que, em geral, Alice gostaria que suas mudanças locais fossem\n+gravadas antes de iniciar este \"pull\".  Se o trabalho de Bobo conflita\n+com o que Alice fez desde que suas histórias se ramificaram, Alice irá\n+usar seu diretório de trabalho e o índice para resolver conflitos, e\n+mudanças locais existentes irão interferir com o processo de resolução\n+de conflitos (git ainda irá realizar a obtenção mas irá se recusar a\n+unificar --- Alice terá que se livrar de suas mudanças locais de alguma\n+forma e puxar de novo quando isso acontecer).\n+\n+Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando\n+\"fetch\"; isto permite Alice inspecionar o que Bob fez, usando um símbolo\n+especial \"FETCH_HEAD\", com o fim de determinar se ele tem alguma coisa\n+que vale puxar, assim:\n+\n+------------------------------------------------\n+alice$ git fetch /home/bob/myrepo master\n+alice$ git log -p HEAD..FETCH_HEAD\n+------------------------------------------------\n+\n+Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.\n+A notação de intervalo \"HEAD..FETCH_HEAD\" significa mostrar tudo que é\n+alcançável de FETCH_HEAD mas exclua tudo que é alcançável de HEAD. Alcie\n+já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob tem\n+em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.\n+\n+Se Alice quer visualizar o que Bob fez desde que suas história\n+ramificaram, ela pode disparar o seguinte comando:\n+\n+------------------------------------------------\n+$ gitk HEAD..FETCH_HEAD\n+------------------------------------------------\n+\n+Isto usar a mesma notação de intervaldo que vimos antes com 'git log'.\n+\n+Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela\n+pode usar a forma com três pontos ao invés da forma com dois pontos:\n+\n+------------------------------------------------\n+$ gitk HEAD...FETCH_HEAD\n+------------------------------------------------\n+\n+Isto significa \"mostre tudo que é alcançavel de qualquer um, mas exclua\n+tudo que é alcançavel a partir de ambos\".\n+This means \"show everything that is reachable from either one, but\n+exclude anything that is reachable from both of them\".\n+\n+Por favor, note que essas notações de intervalo podem ser usadas tanto\n+com gitk quanto com \"git log\".\n+\n+Apoós inspecionar o que Bob fez, se não há nada urgente, Alice pode\n+decidir continuar trabalhando sem puxar de Bob.  Se a história de Bob\n+tem alguma coisa que Alice precisa imediatamente, Alice pode optar por\n+separar seu trabalho em progresso primeiro, fazer um \"pull\", e, então,\n+finalmente, retomar seu trabalho em progresso em cima da história\n+resultante.\n+\n+Quanto você está trabalhando em um pequeno grupo unido, não é incomum\n+interagir com o mesmo repositório várias e várias vezes.  Definindo um\n+repositório remoto antes de tudo, você pode fazê-lo mais facilmente:\n+\n+------------------------------------------------\n+alice$ git remote add bob /home/bob/myrepo\n+------------------------------------------------\n+\n+Com isso, Alice pode executar a primeira parte da operação \"pull\" usando\n+o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,\n+usando:\n+\n+-------------------------------------\n+alice$ git fetch bob\n+-------------------------------------\n+\n+Diferente da forma longa, quando Alice obteve de Bob usando um\n+repositório remoto antes definido com 'git-remote', o que foi obtido é\n+armazenado um ramo remoto, neste caso `bob/master`.  Então, após isso:\n+\n+-------------------------------------\n+alice$ git log -p master..bob/master\n+-------------------------------------\n+\n+mostra uma lista de todas as mudanças que Bob fez desde que ramificou do\n+ramo master de Alice.\n+\n+Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:\n+\n+-------------------------------------\n+alice$ git merge bob/master\n+-------------------------------------\n+\n+Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,\n+assim:\n+\n+-------------------------------------\n+alice$ git pull . remotes/bob/master\n+-------------------------------------\n+\n+Note que 'git pull' sempre unifica ao ramo atual, independente do que\n+mais foi dado na linha de comando.\n+\n+Depois, Bob pode atualizar seu repositório com as últimas mudanças de\n+Alice, usando\n+\n+-------------------------------------\n+bob$ git pull\n+-------------------------------------\n+\n+Note que ele não precisa dar o caminho do repositório de Alice; quando\n+Bob clonou seu repositório, o git armazenou a localização de seu\n+repositório na configuração do repositório, e essa localização é usada\n+para puxar:\n+\n+-------------------------------------\n+bob$ git config --get remote.origin.url\n+/home/alice/project\n+-------------------------------------\n+\n+(A configuração completa criada por 'git-clone' é visível usando `git\n+config -l`, e a página de manual linkgit:git-config[1] explica o\n+significado de cada opção.)\n+\n+Git também mantém uma cópia limpa do ramo master de Alice sob o nome\n+\"origin/master\":\n+\n+-------------------------------------\n+bob$ git branch -r\n+  origin/master\n+-------------------------------------\n+\n+Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode\n+executar clones e puxar usando o protocolo ssh:\n+\n+-------------------------------------\n+bob$ git clone alice.org:/home/alice/project myrepo\n+-------------------------------------\n+\n+Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou\n+http; veja linkgit:git-pull[1] para detalhes.\n+\n+Git pode também ser usado em um modo parecido com CVS, com um\n+repositório central para o qual que vários usuários empurram\n+modificações; veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].\n+\n+Explorando história\n+-----------------\n+\n+A história no git é representada como uma série de commits\n+interrelacionados.  Nós já vimos que o comando 'git-log' pode listar\n+esses commits. Note que a primeira linha de cama entrada no log também\n+dá o nome para o commit:\n+\n+-------------------------------------\n+$ git log\n+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\n+Author: Junio C Hamano <junkio@cox.net>\n+Date:   Tue May 16 17:18:22 2006 -0700\n+\n+    merge-base: Clarify the comments on post processing.\n+-------------------------------------\n+\n+Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este\n+commit.\n+\n+-------------------------------------\n+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\n+-------------------------------------\n+\n+Mas há outras formas de se referir a commits.  Você pode usar qualquer\n+parte inicial do nome que seja longo o bastante para unicamente\n+identificar o commit:\n+\n+-------------------------------------\n+$ git show c82a22c39c\t# os primeiros caracteres do nome são o bastante\n+\t\t\t# usualmente\n+$ git show HEAD\t\t# a ponta do ramo atual\n+$ git show experimental\t# a ponta do ramo \"experimental\"\n+-------------------------------------\n+\n+Todo commit usualmente tem um commit \"pai\" que aponta para o estado\n+anterior do projeto:\n+\n+-------------------------------------\n+$ git show HEAD^  # para ver o pai de HEAD\n+$ git show HEAD^^ # para ver o avô de HEAD\n+$ git show HEAD~4 # para ver o trisavô de HEAD\n+-------------------------------------\n+\n+Note que commits de unificação podem ter mais de um pai:\n+\n+-------------------------------------\n+$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)\n+$ git show HEAD^2 # mostra o segundo pai de HEAD\n+-------------------------------------\n+\n+Você também pode dar aos commits nomes seus; após executar\n+\n+-------------------------------------\n+$ git tag v2.5 1b2e1d63ff\n+-------------------------------------\n+\n+você pode se referir a 1b2e1d63ff pelo nome \"v2.5\".  Se você pretende\n+compartilhar esse nome com outras pessoas (por exemplo, para identificar\n+uma versão de lançamento), você deve criar um objeto \"tag\", e talvez\n+assiná-lo; veja linkgit:git-tag[1] para detalhes.\n+\n+Qualquer comando git que precise conhecer um commit pode receber\n+quaisquer desses nomes.  Por exemplo:\n+\n+-------------------------------------\n+$ git diff v2.5 HEAD\t # compara o HEAD atual com v2.5\n+$ git branch stable v2.5 # inicia um novo ramo chamado \"stable\" baseado\n+\t\t\t # em v2.5\n+$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de\n+\t\t\t # trabalho a seu estado em HEAD^\n+-------------------------------------\n+\n+Seja cuidadoso com o último comando: além de perder quaisquer mudanças\n+em seu diretório de trabalho, ele também remove todos os commits\n+posteriores desse ramo.  Se esse ramo é o único ramo contendo esses\n+commits, eles serão perdidos.  Também, não use 'git-reset' num ramo\n+publicamente visível de onde outros desenvolvedores puxam, já que vai\n+forçar unificações desnecessárias para que outros desenvolvedores limpem\n+a história. Se você precisa desfazer mudanças que você empurrou, use\n+'git-revert' no lugar.\n+\n+O comando 'git-grep' pode buscar strings em qualquer versão de seu\n+projeto, então\n+\n+-------------------------------------\n+$ git grep \"hello\" v2.5\n+-------------------------------------\n+\n+procura por todas as ocorreências de \"hello\" em v2.5.\n+\n+Se você deixar de fora o nome do commit, 'git-grep' irá procurar\n+quaisquer dos arquivos que ele gerencia no diretório corrente.  Então\n+\n+-------------------------------------\n+$ git grep \"hello\"\n+-------------------------------------\n+\n+é uma forma rápida de buscar somente os arquivos que são rastreados pelo\n+git.\n+\n+Muitos comandos git também recebem um conjunto de commits, o que pode\n+ser especificado de um bom número de formas.  Aqui estão alguns exemplos\n+com 'git-log':\n+\n+-------------------------------------\n+$ git log v2.5..v2.6            # commits entre v2.5 e v2.6\n+$ git log v2.5..                # commits desde v2.5\n+$ git log --since=\"2 weeks ago\" # commits das últimas 2 semanas\n+$ git log v2.5.. Makefile       # commits desde v2.5 que modificam\n+\t\t\t\t# Makefile\n+-------------------------------------\n+\n+Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n+primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n+as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n+comum algum tempo atrás, então\n+\n+-------------------------------------\n+$ git log stable..experimental\n+-------------------------------------\n+\n+irá listas os commits feitos no ramo experimental mas não no ramo\n+stable, enquanto\n+\n+-------------------------------------\n+$ git log experimental..stable\n+-------------------------------------\n+\n+irá listar a lista de commits feitos no ramo stable mas não no ramo\n+experimental.\n+\n+O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em\n+uma lista. Quando a história tem linhas de desenvolvimento que\n+divergiram e então foram unificadas novamente, a ordem em que 'git-log'\n+apresenta essas mudanças é insignificante.\n+\n+A maioria dos projetos com múltiplos contribuidores (como o kernel\n+linux, ou o git mesmo) tem unificações frequentes, e 'gitk' faz um\n+trabalho melhor de visualizar sua história.  Por exemplo,\n+\n+-------------------------------------\n+$ gitk --since=\"2 weeks ago\" drivers/\n+-------------------------------------\n+\n+permite você navegar em quaisquer commits desde as últimas duas semanas\n+de commits que modificaram arquivos sob o diretório \"drivers\".  (Nota:\n+você pode ajustar as fontes do gitk segurando a tecla control enquanto\n+pressiona \"-\" ou \"+\".)\n+\n+Finalmente, a maioria dos comandos que recebem nomes de arquivo\n+te permitirão opcionalmente preceder qualquer nome de arquivo por um\n+commit, para especificar uma versão particular do arquivo:\n+\n+-------------------------------------\n+$ git diff v2.5:Makefile HEAD:Makefile.in\n+-------------------------------------\n+\n+Você pode usar 'git-show' para ver tal arquivo:\n+\n+-------------------------------------\n+$ git show v2.5:Makefile\n+-------------------------------------\n+\n+Próximos passos\n+----------\n+\n+Este tutorial deve ser o bastante para operar controle de revisão\n+distribuído básico para seus projetos.  No entanto, para entender\n+plenamente a profundidade e o poder do git você precisa entender duas\n+idéias simples nas quais ele se baseia:\n+\n+  * A base de objetos é um sistema bem elegante usado para armazenar a\n+    história de seu projeto--arquivos, diretórios, e commits.\n+\n+  * O arquivo de índica é um cache do estado de uma árvore de diretório,\n+    usado para criar commits, restaurar diretórios de trabalho, e\n+    compreender as várias árvores involvidas em uma unificação.\n+\n+Parte dois deste tutorial explica a base de objetos, o arquivo de\n+índice, e algumas outras coisinhas que você vai precisar pra usar o\n+máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].\n+\n+Se você não quer continuar do jeito certo, algumas outras disgressões\n+que podem ser interessantes neste ponto são:\n+\n+  * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem\n+    séries de commits em patches em email, e vice-versa, úteis para\n+    projetos como o kernel linux que dependem pesadamente em patches\n+    enviados por email.\n+\n+  * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma\n+    forma de rastrear um bug é procurando pela história para encontrar o\n+    commit culpado.  Git bisect pode ajudar a executar uma busca binária\n+    por esse commit.  Ele é inteligente o bastante para executar uma\n+    busca próxima da ótima mesmo no caso de uma história complexa\n+    não-linear com muitos ramos unificados.\n+\n+  * link:everyday.html[GIT diariamente com 20 e tantos comandos]\n+\n+  * linkgit:gitcvs-migration[7]: Git para usuários de CVS.\n+\n+Veja Também\n+--------\n+linkgit:gittutorial-2[7],\n+linkgit:gitcvs-migration[7],\n+linkgit:gitcore-tutorial[7],\n+linkgit:gitglossary[7],\n+linkgit:git-help[1],\n+link:everyday.html[git diariamente],\n+link:user-manual.html[O Manual do Usuário git]\n+\n+GIT\n+---\n+Parte da suite linkgit:git[1].\n-- \n1.6.3\n"},{"id":"117162","messageId":"7vljnbcbjs.fsf@alter.siamese.dyndns.org","threadId":"19963","inReplyTo":"1246284358-26491-1-git-send-email-cascardo@holoscopio.com","subject":"Re: [PATCH 2/2] Translate the tutorial to Brazillian Portuguese.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-29T15:19:35Z","receivedAt":"2009-06-29T15:19:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.  Sign-off?\n"},{"id":"117163","messageId":"1246289542-1596-1-git-send-email-cascardo@holoscopio.com","threadId":"19963","inReplyTo":"7vljnbcbjs.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"Thadeu Lima de Souza Cascardo","fromEmail":"cascardo@holoscopio.com","sentAt":"2009-06-29T15:32:22Z","receivedAt":"2009-06-29T15:32:22Z","isPatch":true,"sender":{"key":"cascardo@holoscopio.com","avatar":null},"body":"Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>\n---\n Documentation/pt/gittutorial.txt |  679 ++++++++++++++++++++++++++++++++++++++\n 1 files changed, 679 insertions(+), 0 deletions(-)\n create mode 100644 Documentation/pt/gittutorial.txt\n\ndiff --git a/Documentation/pt/gittutorial.txt b/Documentation/pt/gittutorial.txt\nnew file mode 100644\nindex 0000000..25bee03\n--- /dev/null\n+++ b/Documentation/pt/gittutorial.txt\n@@ -0,0 +1,679 @@\n+gittutorial(7)\n+==============\n+\n+NAME\n+----\n+gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)\n+\n+SYNOPSIS\n+--------\n+git *\n+\n+DESCRIPTION\n+-----------\n+\n+Este tutorial explica como importar um novo projeto para o git,\n+adicionar mudanças a ele, e compartilhar mudanças com outros\n+desenvolvedores.\n+\n+If, ao invés disso, você está interessado primariamente em usar git para\n+obter um projeto, por exemplo, para testar a última versão, você pode\n+preferir começar com os primeiros dois capítulos de\n+link:user-manual.html[O Manual do Usuário Git].\n+\n+Primeiro, note que você pode obter documentação para um comando como\n+`git log --graph` com:\n+\n+------------------------------------------------\n+$ man git-log\n+------------------------------------------------\n+\n+ou:\n+\n+------------------------------------------------\n+$ git help log\n+------------------------------------------------\n+\n+Com a última forma, você pode usar o visualizador de manual de sua\n+escolha; veja linkgit:git-help[1] para maior informação.\n+\n+É uma boa idéia se introduzir ao git com seu nome e endereço público de\n+email antes de fazer qualquer operação. A maneira mais fácil de fazê-lo\n+é:\n+\n+------------------------------------------------\n+$ git config --global user.name \"Seu Nome Vem Aqui\"\n+$ git config --global user.email voce@seudominio.exemplo.com\n+------------------------------------------------\n+\n+\n+Importando um novo projeto\n+-----------------------\n+\n+Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.\n+Você pode colocá-lo sob controle de revisão git como a seguir.\n+\n+------------------------------------------------\n+$ tar xzf project.tar.gz\n+$ cd project\n+$ git init\n+------------------------------------------------\n+\n+Git irá responder\n+\n+------------------------------------------------\n+Initialized empty Git repository in .git/\n+------------------------------------------------\n+\n+Você agora iniciou seu diretório de trabalho--você deve ter notado um\n+novo diretório criado, com o nome de \".git\".\n+\n+A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os\n+arquivos sob o diretório corrente (note o '.'), com 'git-add':\n+\n+------------------------------------------------\n+$ git add .\n+------------------------------------------------\n+\n+Este instantâneo está agora armazenado em uma área temporária que o git\n+chama de \"index\" ou índice. Você pode permanetemente armazenar o\n+conteúdo do índice no repositório com 'git-commit':\n+\n+------------------------------------------------\n+$ git commit\n+------------------------------------------------\n+\n+Isto vai te pedir por uma mensagem de commit. Você agora gravou sua\n+primeira versão de seu projeto no git.\n+\n+Fazendo mudanças\n+--------------\n+\n+Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao\n+índice:\n+\n+------------------------------------------------\n+$ git add file1 file2 file3\n+------------------------------------------------\n+\n+Você está agora pronto para fazer o commit. Você pode ver o que está\n+para ser gravado usando 'git-diff' com a opção --cached:\n+\n+------------------------------------------------\n+$ git diff --cached\n+------------------------------------------------\n+\n+(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças\n+que você tenha feito mas ainda não adicionou ao índice.) Você também\n+pode obter um breve sumário da situação com 'git-status':\n+\n+------------------------------------------------\n+$ git status\n+# On branch master\n+# Changes to be committed:\n+#   (use \"git reset HEAD <file>...\" to unstage)\n+#\n+#\tmodified:   file1\n+#\tmodified:   file2\n+#\tmodified:   file3\n+#\n+------------------------------------------------\n+\n+Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,\n+adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas\n+mudanças com:\n+\n+------------------------------------------------\n+$ git commit\n+------------------------------------------------\n+\n+Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e,\n+então, gravar a nova versão do projeto.\n+\n+Alternativamente, ao invés de executar 'git-add' antes, você pode usar\n+\n+------------------------------------------------\n+$ git commit -a\n+------------------------------------------------\n+\n+o que irá automaticamente notar quaisquer arquivos modificados (mas não\n+novos), adicioná-los ao índices, e gravar, tudo em um único passo.\n+\n+Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa\n+idéia começar a mensagem com uma simples e curta (menos de 50\n+caracteres) linha sumarizando a mudança, seguida de uma linha em branco\n+e, então, uma descrição mais detalhada.  Ferramentas que transformam\n+commits em email, por exemplo, usam a primeira linha no campo de\n+cabeçalho Subject: e o resto no corpo.\n+\n+Git rastreia conteúdo, não arquivos\n+----------------------------\n+\n+Muitos sistemas de controle de revisão provêem um comando `add` que diz\n+ao sistema para começar a rastrear mudanças em um novo arquivo.  O\n+comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é\n+usado tanto para arquivos novos e arquivos recentemente modificados, e\n+em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena\n+o conteúdo no índice, pronto para inclusão do próximo commit.\n+\n+Visualizando história do projeto\n+-----------------------\n+\n+Em qualquer ponto você pode visualizar a história das suas mudanças\n+usando\n+\n+------------------------------------------------\n+$ git log\n+------------------------------------------------\n+\n+Se você também quer ver a diferença completa a cada passo, use\n+\n+------------------------------------------------\n+$ git log -p\n+------------------------------------------------\n+\n+Geralmente, uma visão geral da mudança é útil para ter a sensação de\n+cada passo\n+\n+------------------------------------------------\n+$ git log --stat --summary\n+------------------------------------------------\n+\n+Gerenciando \"branches\"/ramos\n+-----------------\n+\n+Um simples repositório git pode manter múltiplos ramos de\n+desenvolvimento.  Para criar um novo ramo chamado \"experimental\", use\n+\n+------------------------------------------------\n+$ git branch experimental\n+------------------------------------------------\n+\n+Se você executar agora\n+\n+------------------------------------------------\n+$ git branch\n+------------------------------------------------\n+\n+você vai obter uma lista de todos os ramos existentes:\n+\n+------------------------------------------------\n+  experimental\n+* master\n+------------------------------------------------\n+\n+O ramo \"experimental\" é o que você acaba de criar, e o ramo \"master\" é o\n+ramo padrão que foi criado pra você automaticamente.  O asterisco marca\n+o ramo em que você está atualmente; digite\n+\n+------------------------------------------------\n+$ git checkout experimental\n+------------------------------------------------\n+\n+para mudar para o ramo experimental.  Agora edite um arquivo, grave a\n+mudança, e mude de volta para o ramo master:\n+\n+------------------------------------------------\n+(edita arquivo)\n+$ git commit -a\n+$ git checkout master\n+------------------------------------------------\n+\n+Verifique que a mudança que você fez não está mais visível, já que ela\n+foi feita no ramo experimental e você está de volta ao ramo master.\n+\n+Você pode fazer uma mudança diferente no ramo master:\n+\n+------------------------------------------------\n+(edit file)\n+$ git commit -a\n+------------------------------------------------\n+\n+neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em\n+cada um.  Para unificar as mudanças feitas no experimental para o\n+master, execute\n+\n+------------------------------------------------\n+$ git merge experimental\n+------------------------------------------------\n+\n+Se as mudanças não conflitam, está pronto.  Se existirem conflitos,\n+marcadores serão deixados nos arquivos problemáticos exibindo o\n+conflito;\n+\n+------------------------------------------------\n+$ git diff\n+------------------------------------------------\n+\n+vai exibir isto.  Após você editar os arquivos para resolver os\n+conflitos,\n+\n+------------------------------------------------\n+$ git commit -a\n+------------------------------------------------\n+\n+irá gravar o resultado da unificação. Finalmente,\n+\n+------------------------------------------------\n+$ gitk\n+------------------------------------------------\n+\n+vai mostrar uma bela representação gráfica da história resultante.\n+\n+Neste ponto você pode remover seu ramo experimental com\n+\n+------------------------------------------------\n+$ git branch -d experimental\n+------------------------------------------------\n+\n+Este comando garante que as mudanças no ramo experimental já estão no\n+ramo atual.\n+\n+Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode\n+sempre remover o ramo com\n+\n+-------------------------------------\n+$ git branch -D crazy-idea\n+-------------------------------------\n+\n+Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar\n+alguma coisa.\n+\n+Usando git para colaboração\n+---------------------------\n+\n+Suponha que Alice começou um novo projeto com um repositório git em\n+/home/alice/project, e que Bob, que tem um diretório home na mesma\n+máquina, quer contribuir.\n+\n+Bob começa com:\n+\n+------------------------------------------------\n+bob$ git clone /home/alice/project myrepo\n+------------------------------------------------\n+\n+Isso cria um novo diretório \"myrepo\" contendo um clone do repositório de\n+Alice.  O clone está no mesmo pé que o projeto original, possuindo sua\n+própria cópia da história do projeto original.\n+\n+Bob então faz algumas mudanças e as grava:\n+\n+------------------------------------------------\n+(editar arquivos)\n+bob$ git commit -a\n+(repetir conforme necessário)\n+------------------------------------------------\n+\n+Quanto está pronto, ele diz a Alice para puxar as mudanças do\n+repositório em /home/bob/myrepo.  Ela o faz com:\n+\n+------------------------------------------------\n+alice$ cd /home/alice/project\n+alice$ git pull /home/bob/myrepo master\n+------------------------------------------------\n+\n+Isto unifica as mudanças do ramo \"master\" do Bob ao ramo atual de Alice.\n+Se Alice fez suas próprias mudanças no intervalo, ela, então, pode\n+precisar corrigir manualmente quaiquer conflitos.  (Note que o argumento\n+\"master\" no comando acima é, de fato, desnecessário, já que é o padrão.)\n+\n+O comando \"pull\" executa, então, duas operações: ele obtém mudanças de\n+um ramo remoto, e, então, as unifica no ramo atual.\n+\n+Note que, em geral, Alice gostaria que suas mudanças locais fossem\n+gravadas antes de iniciar este \"pull\".  Se o trabalho de Bobo conflita\n+com o que Alice fez desde que suas histórias se ramificaram, Alice irá\n+usar seu diretório de trabalho e o índice para resolver conflitos, e\n+mudanças locais existentes irão interferir com o processo de resolução\n+de conflitos (git ainda irá realizar a obtenção mas irá se recusar a\n+unificar --- Alice terá que se livrar de suas mudanças locais de alguma\n+forma e puxar de novo quando isso acontecer).\n+\n+Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando\n+\"fetch\"; isto permite Alice inspecionar o que Bob fez, usando um símbolo\n+especial \"FETCH_HEAD\", com o fim de determinar se ele tem alguma coisa\n+que vale puxar, assim:\n+\n+------------------------------------------------\n+alice$ git fetch /home/bob/myrepo master\n+alice$ git log -p HEAD..FETCH_HEAD\n+------------------------------------------------\n+\n+Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.\n+A notação de intervalo \"HEAD..FETCH_HEAD\" significa mostrar tudo que é\n+alcançável de FETCH_HEAD mas exclua tudo que é alcançável de HEAD. Alcie\n+já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob tem\n+em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.\n+\n+Se Alice quer visualizar o que Bob fez desde que suas história\n+ramificaram, ela pode disparar o seguinte comando:\n+\n+------------------------------------------------\n+$ gitk HEAD..FETCH_HEAD\n+------------------------------------------------\n+\n+Isto usar a mesma notação de intervaldo que vimos antes com 'git log'.\n+\n+Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela\n+pode usar a forma com três pontos ao invés da forma com dois pontos:\n+\n+------------------------------------------------\n+$ gitk HEAD...FETCH_HEAD\n+------------------------------------------------\n+\n+Isto significa \"mostre tudo que é alcançavel de qualquer um, mas exclua\n+tudo que é alcançavel a partir de ambos\".\n+This means \"show everything that is reachable from either one, but\n+exclude anything that is reachable from both of them\".\n+\n+Por favor, note que essas notações de intervalo podem ser usadas tanto\n+com gitk quanto com \"git log\".\n+\n+Apoós inspecionar o que Bob fez, se não há nada urgente, Alice pode\n+decidir continuar trabalhando sem puxar de Bob.  Se a história de Bob\n+tem alguma coisa que Alice precisa imediatamente, Alice pode optar por\n+separar seu trabalho em progresso primeiro, fazer um \"pull\", e, então,\n+finalmente, retomar seu trabalho em progresso em cima da história\n+resultante.\n+\n+Quanto você está trabalhando em um pequeno grupo unido, não é incomum\n+interagir com o mesmo repositório várias e várias vezes.  Definindo um\n+repositório remoto antes de tudo, você pode fazê-lo mais facilmente:\n+\n+------------------------------------------------\n+alice$ git remote add bob /home/bob/myrepo\n+------------------------------------------------\n+\n+Com isso, Alice pode executar a primeira parte da operação \"pull\" usando\n+o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,\n+usando:\n+\n+-------------------------------------\n+alice$ git fetch bob\n+-------------------------------------\n+\n+Diferente da forma longa, quando Alice obteve de Bob usando um\n+repositório remoto antes definido com 'git-remote', o que foi obtido é\n+armazenado um ramo remoto, neste caso `bob/master`.  Então, após isso:\n+\n+-------------------------------------\n+alice$ git log -p master..bob/master\n+-------------------------------------\n+\n+mostra uma lista de todas as mudanças que Bob fez desde que ramificou do\n+ramo master de Alice.\n+\n+Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:\n+\n+-------------------------------------\n+alice$ git merge bob/master\n+-------------------------------------\n+\n+Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,\n+assim:\n+\n+-------------------------------------\n+alice$ git pull . remotes/bob/master\n+-------------------------------------\n+\n+Note que 'git pull' sempre unifica ao ramo atual, independente do que\n+mais foi dado na linha de comando.\n+\n+Depois, Bob pode atualizar seu repositório com as últimas mudanças de\n+Alice, usando\n+\n+-------------------------------------\n+bob$ git pull\n+-------------------------------------\n+\n+Note que ele não precisa dar o caminho do repositório de Alice; quando\n+Bob clonou seu repositório, o git armazenou a localização de seu\n+repositório na configuração do repositório, e essa localização é usada\n+para puxar:\n+\n+-------------------------------------\n+bob$ git config --get remote.origin.url\n+/home/alice/project\n+-------------------------------------\n+\n+(A configuração completa criada por 'git-clone' é visível usando `git\n+config -l`, e a página de manual linkgit:git-config[1] explica o\n+significado de cada opção.)\n+\n+Git também mantém uma cópia limpa do ramo master de Alice sob o nome\n+\"origin/master\":\n+\n+-------------------------------------\n+bob$ git branch -r\n+  origin/master\n+-------------------------------------\n+\n+Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode\n+executar clones e puxar usando o protocolo ssh:\n+\n+-------------------------------------\n+bob$ git clone alice.org:/home/alice/project myrepo\n+-------------------------------------\n+\n+Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou\n+http; veja linkgit:git-pull[1] para detalhes.\n+\n+Git pode também ser usado em um modo parecido com CVS, com um\n+repositório central para o qual que vários usuários empurram\n+modificações; veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].\n+\n+Explorando história\n+-----------------\n+\n+A história no git é representada como uma série de commits\n+interrelacionados.  Nós já vimos que o comando 'git-log' pode listar\n+esses commits. Note que a primeira linha de cama entrada no log também\n+dá o nome para o commit:\n+\n+-------------------------------------\n+$ git log\n+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\n+Author: Junio C Hamano <junkio@cox.net>\n+Date:   Tue May 16 17:18:22 2006 -0700\n+\n+    merge-base: Clarify the comments on post processing.\n+-------------------------------------\n+\n+Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este\n+commit.\n+\n+-------------------------------------\n+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\n+-------------------------------------\n+\n+Mas há outras formas de se referir a commits.  Você pode usar qualquer\n+parte inicial do nome que seja longo o bastante para unicamente\n+identificar o commit:\n+\n+-------------------------------------\n+$ git show c82a22c39c\t# os primeiros caracteres do nome são o bastante\n+\t\t\t# usualmente\n+$ git show HEAD\t\t# a ponta do ramo atual\n+$ git show experimental\t# a ponta do ramo \"experimental\"\n+-------------------------------------\n+\n+Todo commit usualmente tem um commit \"pai\" que aponta para o estado\n+anterior do projeto:\n+\n+-------------------------------------\n+$ git show HEAD^  # para ver o pai de HEAD\n+$ git show HEAD^^ # para ver o avô de HEAD\n+$ git show HEAD~4 # para ver o trisavô de HEAD\n+-------------------------------------\n+\n+Note que commits de unificação podem ter mais de um pai:\n+\n+-------------------------------------\n+$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)\n+$ git show HEAD^2 # mostra o segundo pai de HEAD\n+-------------------------------------\n+\n+Você também pode dar aos commits nomes seus; após executar\n+\n+-------------------------------------\n+$ git tag v2.5 1b2e1d63ff\n+-------------------------------------\n+\n+você pode se referir a 1b2e1d63ff pelo nome \"v2.5\".  Se você pretende\n+compartilhar esse nome com outras pessoas (por exemplo, para identificar\n+uma versão de lançamento), você deve criar um objeto \"tag\", e talvez\n+assiná-lo; veja linkgit:git-tag[1] para detalhes.\n+\n+Qualquer comando git que precise conhecer um commit pode receber\n+quaisquer desses nomes.  Por exemplo:\n+\n+-------------------------------------\n+$ git diff v2.5 HEAD\t # compara o HEAD atual com v2.5\n+$ git branch stable v2.5 # inicia um novo ramo chamado \"stable\" baseado\n+\t\t\t # em v2.5\n+$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de\n+\t\t\t # trabalho a seu estado em HEAD^\n+-------------------------------------\n+\n+Seja cuidadoso com o último comando: além de perder quaisquer mudanças\n+em seu diretório de trabalho, ele também remove todos os commits\n+posteriores desse ramo.  Se esse ramo é o único ramo contendo esses\n+commits, eles serão perdidos.  Também, não use 'git-reset' num ramo\n+publicamente visível de onde outros desenvolvedores puxam, já que vai\n+forçar unificações desnecessárias para que outros desenvolvedores limpem\n+a história. Se você precisa desfazer mudanças que você empurrou, use\n+'git-revert' no lugar.\n+\n+O comando 'git-grep' pode buscar strings em qualquer versão de seu\n+projeto, então\n+\n+-------------------------------------\n+$ git grep \"hello\" v2.5\n+-------------------------------------\n+\n+procura por todas as ocorreências de \"hello\" em v2.5.\n+\n+Se você deixar de fora o nome do commit, 'git-grep' irá procurar\n+quaisquer dos arquivos que ele gerencia no diretório corrente.  Então\n+\n+-------------------------------------\n+$ git grep \"hello\"\n+-------------------------------------\n+\n+é uma forma rápida de buscar somente os arquivos que são rastreados pelo\n+git.\n+\n+Muitos comandos git também recebem um conjunto de commits, o que pode\n+ser especificado de um bom número de formas.  Aqui estão alguns exemplos\n+com 'git-log':\n+\n+-------------------------------------\n+$ git log v2.5..v2.6            # commits entre v2.5 e v2.6\n+$ git log v2.5..                # commits desde v2.5\n+$ git log --since=\"2 weeks ago\" # commits das últimas 2 semanas\n+$ git log v2.5.. Makefile       # commits desde v2.5 que modificam\n+\t\t\t\t# Makefile\n+-------------------------------------\n+\n+Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n+primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n+as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n+comum algum tempo atrás, então\n+\n+-------------------------------------\n+$ git log stable..experimental\n+-------------------------------------\n+\n+irá listas os commits feitos no ramo experimental mas não no ramo\n+stable, enquanto\n+\n+-------------------------------------\n+$ git log experimental..stable\n+-------------------------------------\n+\n+irá listar a lista de commits feitos no ramo stable mas não no ramo\n+experimental.\n+\n+O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em\n+uma lista. Quando a história tem linhas de desenvolvimento que\n+divergiram e então foram unificadas novamente, a ordem em que 'git-log'\n+apresenta essas mudanças é insignificante.\n+\n+A maioria dos projetos com múltiplos contribuidores (como o kernel\n+linux, ou o git mesmo) tem unificações frequentes, e 'gitk' faz um\n+trabalho melhor de visualizar sua história.  Por exemplo,\n+\n+-------------------------------------\n+$ gitk --since=\"2 weeks ago\" drivers/\n+-------------------------------------\n+\n+permite você navegar em quaisquer commits desde as últimas duas semanas\n+de commits que modificaram arquivos sob o diretório \"drivers\".  (Nota:\n+você pode ajustar as fontes do gitk segurando a tecla control enquanto\n+pressiona \"-\" ou \"+\".)\n+\n+Finalmente, a maioria dos comandos que recebem nomes de arquivo\n+te permitirão opcionalmente preceder qualquer nome de arquivo por um\n+commit, para especificar uma versão particular do arquivo:\n+\n+-------------------------------------\n+$ git diff v2.5:Makefile HEAD:Makefile.in\n+-------------------------------------\n+\n+Você pode usar 'git-show' para ver tal arquivo:\n+\n+-------------------------------------\n+$ git show v2.5:Makefile\n+-------------------------------------\n+\n+Próximos passos\n+----------\n+\n+Este tutorial deve ser o bastante para operar controle de revisão\n+distribuído básico para seus projetos.  No entanto, para entender\n+plenamente a profundidade e o poder do git você precisa entender duas\n+idéias simples nas quais ele se baseia:\n+\n+  * A base de objetos é um sistema bem elegante usado para armazenar a\n+    história de seu projeto--arquivos, diretórios, e commits.\n+\n+  * O arquivo de índica é um cache do estado de uma árvore de diretório,\n+    usado para criar commits, restaurar diretórios de trabalho, e\n+    compreender as várias árvores involvidas em uma unificação.\n+\n+Parte dois deste tutorial explica a base de objetos, o arquivo de\n+índice, e algumas outras coisinhas que você vai precisar pra usar o\n+máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].\n+\n+Se você não quer continuar do jeito certo, algumas outras disgressões\n+que podem ser interessantes neste ponto são:\n+\n+  * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem\n+    séries de commits em patches em email, e vice-versa, úteis para\n+    projetos como o kernel linux que dependem pesadamente em patches\n+    enviados por email.\n+\n+  * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma\n+    forma de rastrear um bug é procurando pela história para encontrar o\n+    commit culpado.  Git bisect pode ajudar a executar uma busca binária\n+    por esse commit.  Ele é inteligente o bastante para executar uma\n+    busca próxima da ótima mesmo no caso de uma história complexa\n+    não-linear com muitos ramos unificados.\n+\n+  * link:everyday.html[GIT diariamente com 20 e tantos comandos]\n+\n+  * linkgit:gitcvs-migration[7]: Git para usuários de CVS.\n+\n+Veja Também\n+--------\n+linkgit:gittutorial-2[7],\n+linkgit:gitcvs-migration[7],\n+linkgit:gitcore-tutorial[7],\n+linkgit:gitglossary[7],\n+linkgit:git-help[1],\n+link:everyday.html[git diariamente],\n+link:user-manual.html[O Manual do Usuário git]\n+\n+GIT\n+---\n+Parte da suite linkgit:git[1].\n-- \n1.6.3\n"},{"id":"117164","messageId":"7vfxdjc9b3.fsf@alter.siamese.dyndns.org","threadId":"19963","inReplyTo":"1246289542-1596-1-git-send-email-cascardo@holoscopio.com","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-29T16:08:00Z","receivedAt":"2009-06-29T16:08:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:\n\n> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>\n\nThanks.\n\n> +Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n> +primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n> +as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n> +comum algum tempo atrás, então\n> +\n> +-------------------------------------\n> +$ git log stable..experimental\n> +-------------------------------------\n> +\n> +irá listas os commits feitos no ramo experimental mas não no ramo\n> +stable, enquanto\n> +\n> +-------------------------------------\n> +$ git log experimental..stable\n> +-------------------------------------\n> +\n> +irá listar a lista de commits feitos no ramo stable mas não no ramo\n> +experimental.\n> +\n\nI think you would want to update this part to match what you did in your\n[PATCH 1/2 v2].\n\n    By the way, I think your MUA sent quoted-printable UTF-8 but somewhere\n    between your keyboard and vger the message was marked with content-type\n    charset=ISO-8859-1); I fixed it up when quoting the above.\n\nI am somewhat worried about the way how this translation will be\nmaintained to keep in sync with the authoritative English version.\nNarita-san (CC'ed) who translated the document to Japanese did this:\n\n    gittutorial(7)\n    ==============\n    // = gittutorial(7)\n\n    NAME\n    ----\n    // == NAME\n    gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)\n    // gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n\nand the idea seems that without // (comments in AsciiDoc markup) it\nmatches the English copy, and after passing sed -ne 's|^// ||p' it yields\nJapanese version.  Narita-san's translation can be seen at\n\n    http://github.com/yasuaki/git-manual-jp.git/Documentation\n\nif anybody is interested.\n\nWith this format, merging upstream changes may not work as smoothly as it\ncould be, but at least you can check which part of your translation is\nbased on a stale copy with something like this arrangement.\n\nI am wondering if it would be a good idea to extend Narita-san's scheme so\nthat we can keep a single source, perhaps like:\n\n    = gittutorial(7)\n    // ja = gittutorial(7)\n    // pt = gittutorial(7)\n    == NAME\n    // ja = NAME\n    // pt = NAME\n    gittutorial - A tutorial introduction to git (for version 1.5.1 or ...\n    // ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n    // pt gittutorial - Um tutorial de introdução ao git (para versão 1....\n\nThen whenever somebody makes a change to the English version, he can and\nshould also mark the corresponding translated versions \"stale\", so that it\nis easier to spot by translators.\n\n    diff --git a/gittutorial.txt b/gittutorial.txt\n    index 4478300..02d67d3 100644\n    --- a/gittutorial.txt\n    +++ b/gittutorial.txt\n    @@ -4,7 +4,6 @@\n     == NAME\n     // ja = NAME\n     // pt = NAME\n    -gittutorial - A tutorial introduction to git (for version 1.5.1 or n...\n    -// ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n    -// pt gittutorial - Um tutorial de introdução ao git (para versão 1....\n    -\n    +gittutorial - A tutorial introduction to git (for version 1.6.3 or n...\n    +// **stale** ja gittutorial - git チュートリアル (バージョン 1.5.1 ...\n    +// **stale** pt gittutorial - Um tutorial de introdução ao git (par...\n\nAs long as all the translations use the same encoding (I think UTF-8 is\nthe only practical choice for this), keeping translated strings in a\nsingle file would be doable.\n\nI however am not sure how practical it would be to force people to look at\nthe *.txt version of document, only 1/n lines of which is now readable by\nhim (if you are like a typical American who understands only English ;-).\n\nThoughts?\n"},{"id":"117166","messageId":"20090629162738.GE4327@vespa.holoscopio.com","threadId":"19963","inReplyTo":"7vfxdjc9b3.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"Thadeu Lima de Souza Cascardo","fromEmail":"cascardo@holoscopio.com","sentAt":"2009-06-29T16:27:39Z","receivedAt":"2009-06-29T16:27:39Z","isPatch":true,"sender":{"key":"cascardo@holoscopio.com","avatar":null},"body":"On Mon, Jun 29, 2009 at 09:08:00AM -0700, Junio C Hamano wrote:\n> Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:\n> \n> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>\n> \n> Thanks.\n> \n> > +Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n> > +as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n> > +comum algum tempo atrás, então\n> > +\n> > +-------------------------------------\n> > +$ git log stable..experimental\n> > +-------------------------------------\n> > +\n> > +irá listas os commits feitos no ramo experimental mas não no ramo\n> > +stable, enquanto\n> > +\n> > +-------------------------------------\n> > +$ git log experimental..stable\n> > +-------------------------------------\n> > +\n> > +irá listar a lista de commits feitos no ramo stable mas não no ramo\n> > +experimental.\n> > +\n> \n> I think you would want to update this part to match what you did in your\n> [PATCH 1/2 v2].\n> \n\nWell remembered. Thanks.\n\n>     By the way, I think your MUA sent quoted-printable UTF-8 but somewhere\n>     between your keyboard and vger the message was marked with content-type\n>     charset=ISO-8859-1); I fixed it up when quoting the above.\n> \n\nI am going to take a look at it.\n\n> I am somewhat worried about the way how this translation will be\n> maintained to keep in sync with the authoritative English version.\n> Narita-san (CC'ed) who translated the document to Japanese did this:\n> \n>     gittutorial(7)\n>     ==============\n>     // = gittutorial(7)\n> \n>     NAME\n>     ----\n>     // == NAME\n>     gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)\n>     // gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n> \n> and the idea seems that without // (comments in AsciiDoc markup) it\n> matches the English copy, and after passing sed -ne 's|^// ||p' it yields\n> Japanese version.  Narita-san's translation can be seen at\n> \n>     http://github.com/yasuaki/git-manual-jp.git/Documentation\n> \n> if anybody is interested.\n> \n> With this format, merging upstream changes may not work as smoothly as it\n> could be, but at least you can check which part of your translation is\n> based on a stale copy with something like this arrangement.\n> \n> I am wondering if it would be a good idea to extend Narita-san's scheme so\n> that we can keep a single source, perhaps like:\n> \n>     = gittutorial(7)\n>     // ja = gittutorial(7)\n>     // pt = gittutorial(7)\n>     == NAME\n>     // ja = NAME\n>     // pt = NAME\n>     gittutorial - A tutorial introduction to git (for version 1.5.1 or ...\n>     // ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n>     // pt gittutorial - Um tutorial de introdução ao git (para versão 1....\n> \n> Then whenever somebody makes a change to the English version, he can and\n> should also mark the corresponding translated versions \"stale\", so that it\n> is easier to spot by translators.\n> \n>     diff --git a/gittutorial.txt b/gittutorial.txt\n>     index 4478300..02d67d3 100644\n>     --- a/gittutorial.txt\n>     +++ b/gittutorial.txt\n>     @@ -4,7 +4,6 @@\n>      == NAME\n>      // ja = NAME\n>      // pt = NAME\n>     -gittutorial - A tutorial introduction to git (for version 1.5.1 or n...\n>     -// ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n>     -// pt gittutorial - Um tutorial de introdução ao git (para versão 1....\n>     -\n>     +gittutorial - A tutorial introduction to git (for version 1.6.3 or n...\n>     +// **stale** ja gittutorial - git チュートリアル (バージョン 1.5.1 ...\n>     +// **stale** pt gittutorial - Um tutorial de introdução ao git (par...\n> \n> As long as all the translations use the same encoding (I think UTF-8 is\n> the only practical choice for this), keeping translated strings in a\n> single file would be doable.\n> \n> I however am not sure how practical it would be to force people to look at\n> the *.txt version of document, only 1/n lines of which is now readable by\n> him (if you are like a typical American who understands only English ;-).\n> \n> Thoughts?\n\nI think that using something like po would be better. There are tools\nthat can extract and update the template messages from many differente\nsources. Adapting them to produce a template file from gittutorial.txt\nwould allow translators to verify how stale their translations are and\nmuch smoother merges. How about that?\n\nRegards,\nCascardo.\n"},{"id":"117167","messageId":"m3prcnvw3v.fsf@localhost.localdomain","threadId":"19963","inReplyTo":"7vfxdjc9b3.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-29T16:33:06Z","receivedAt":"2009-06-29T16:33:06Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:\n\n> > +Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n> > +as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n> > +comum algum tempo atrás, então\n> > +\n> > +-------------------------------------\n> > +$ git log stable..experimental\n> > +-------------------------------------\n \n> I am somewhat worried about the way how this translation will be\n> maintained to keep in sync with the authoritative English version.\n> Narita-san (CC'ed) who translated the document to Japanese did this:\n> \n>     gittutorial(7)\n>     ==============\n>     // = gittutorial(7)\n> \n>     NAME\n>     ----\n>     // == NAME\n>     gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)\n>     // gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n> \n> and the idea seems that without // (comments in AsciiDoc markup) it\n> matches the English copy, and after passing sed -ne 's|^// ||p' it yields\n> Japanese version.  Narita-san's translation can be seen at\n> \n>     http://github.com/yasuaki/git-manual-jp.git/Documentation\n> \n> if anybody is interested.\n> \n> With this format, merging upstream changes may not work as smoothly as it\n> could be, but at least you can check which part of your translation is\n> based on a stale copy with something like this arrangement.\n> \n> I am wondering if it would be a good idea to extend Narita-san's scheme so\n> that we can keep a single source, perhaps like:\n> \n>     = gittutorial(7)\n>     // ja = gittutorial(7)\n>     // pt = gittutorial(7)\n>     == NAME\n>     // ja = NAME\n>     // pt = NAME\n>     gittutorial - A tutorial introduction to git (for version 1.5.1 or ...\n>     // ja gittutorial - git チュートリアル (バージョン 1.5.1 以降用)\n>     // pt gittutorial - Um tutorial de introdução ao git (para versão 1....\n> \n> Then whenever somebody makes a change to the English version, he can and\n> should also mark the corresponding translated versions \"stale\", so that it\n> is easier to spot by translators.\n\n[...]\n> I however am not sure how practical it would be to force people to look at\n> the *.txt version of document, only 1/n lines of which is now readable by\n> him (if you are like a typical American who understands only English ;-).\n> \n> Thoughts?\n\nSomebody here (or on #git channel) pointed that there is po4a[1-4]\nproject using gettext to translate documentation.\n\n[1] http://po4a.alioth.debian.org/\n[2] https://launchpad.net/po4a\n[3] http://freshmeat.net/projects/po4a\n[4] http://www.ohloh.net/p/po4a\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"117172","messageId":"7vtz1yc2i3.fsf@alter.siamese.dyndns.org","threadId":"19963","inReplyTo":"20090629162738.GE4327@vespa.holoscopio.com","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-29T18:35:00Z","receivedAt":"2009-06-29T18:35:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:\n\n> On Mon, Jun 29, 2009 at 09:08:00AM -0700, Junio C Hamano wrote:\n>> Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> writes:\n>> \n>> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>\n>> \n>> Thanks.\n>> \n>> > +Você também pode dar ao 'git-log' um \"intervalo\" de commits onde o\n>> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se\n>> > +as pontas dos ramos \"stable\" e \"master\" divergiram de um commit\n>> > +comum algum tempo atrás, então\n>> > +\n>> > +-------------------------------------\n>> > +$ git log stable..experimental\n>> > +-------------------------------------\n>> > +\n>> > +irá listas os commits feitos no ramo experimental mas não no ramo\n>> > +stable, enquanto\n>> > +\n>> > +-------------------------------------\n>> > +$ git log experimental..stable\n>> > +-------------------------------------\n>> > +\n>> > +irá listar a lista de commits feitos no ramo stable mas não no ramo\n>> > +experimental.\n>> > +\n>> \n>> I think you would want to update this part to match what you did in your\n>> [PATCH 1/2 v2].\n>\n> Well remembered. Thanks.\n\nAs I do not speak the language, even though I can guess that a straight\nreplacement \"s/experimental/master/g\" would be enough for the above quoted\npart (including the body text), I do not feel comfortable enough to update\nthese myself.  Please send in a replacement [PATCH 2/2 v2].\n\n>> I however am not sure how practical it would be to force people to look at\n>> the *.txt version of document, only 1/n lines of which is now readable by\n>> him (if you are like a typical American who understands only English ;-).\n>> \n>> Thoughts?\n>\n> I think that using something like po would be better. There are tools\n> that can extract and update the template messages from many differente\n> sources. Adapting them to produce a template file from gittutorial.txt\n> would allow translators to verify how stale their translations are and\n> much smoother merges. How about that?\n\nAfter thinking about it a bit more, I think I would prefer something that\nkeeps translation sources separate from the original text.  That way, I\nhave a lot less chance of having to deal with merge/patch conflicts.\n\nYour patch adds Documentation/pt/ hierarchy, but I noticed that the kernel\nfolks seem to use Documentation/{ja_JP,ko_KR,zh_CN}/.  I do not think it\nwould make much difference for Japanese language between ja vs ja_JP, but\nfor many languages used in different geographic areas, such an arrangement\nwould make a lot more sense.  As your patch identified itself as a\ntranslation to \"Brasilian Portuguese\", I am imagining that it would be\nsufficiently different to merit the distinction from Old-world Portuguese.\nPerhaps your patch should be made to Documentation/pt_BR instead?\n\nAs to the choice of the tool, from a quick superficial glance, po4a could\nbe a reasonable choice, but I do not know how mature and/or widely used it\nis, or if there are better alternatives.  http://po4a.alioth.debian.org/\nsays it does support AsciiDoc.\n"},{"id":"119148","messageId":"b8bf37780907292026q61805aadhd2019eae77739c47@mail.gmail.com","threadId":"19963","inReplyTo":"7vtz1yc2i3.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"André Goddard Rosa","fromEmail":"andre.goddard@gmail.com","sentAt":"2009-07-30T03:26:14Z","receivedAt":"2009-07-30T03:26:14Z","isPatch":true,"sender":{"key":"andre.goddard@gmail.com","avatar":null},"body":">> I think that using something like po would be better. There are tools\n>> that can extract and update the template messages from many differente\n>> sources. Adapting them to produce a template file from gittutorial.txt\n>> would allow translators to verify how stale their translations are and\n>> much smoother merges. How about that?\n>\n> After thinking about it a bit more, I think I would prefer something that\n> keeps translation sources separate from the original text.  That way, I\n> have a lot less chance of having to deal with merge/patch conflicts.\n>\n> Your patch adds Documentation/pt/ hierarchy, but I noticed that the kernel\n> folks seem to use Documentation/{ja_JP,ko_KR,zh_CN}/.  I do not think it\n> would make much difference for Japanese language between ja vs ja_JP, but\n> for many languages used in different geographic areas, such an arrangement\n> would make a lot more sense.  As your patch identified itself as a\n> translation to \"Brasilian Portuguese\", I am imagining that it would be\n> sufficiently different to merit the distinction from Old-world Portuguese.\n> Perhaps your patch should be made to Documentation/pt_BR instead?\n>\n> As to the choice of the tool, from a quick superficial glance, po4a could\n> be a reasonable choice, but I do not know how mature and/or widely used it\n> is, or if there are better alternatives.  http://po4a.alioth.debian.org/\n> says it does support AsciiDoc.\n\ngit gui uses 'po' at http://repo.or.cz/w/git-gui/git-gui-i18n.git to\nhandle all translations, including Brazilian Portuguese.\n\nIn the meantime, I've made some translation improvements over Thadeu's\ntranslation work, fixing some typos overall. I'll send it as a\nseparate patch.\n\n@Thadeu: would you please double check it and perhaps add your Acked-by?\n\nThanks,\nAndre\n"},{"id":"119174","messageId":"20090730154446.GD1727@vespa.holoscopio.com","threadId":"19963","inReplyTo":"b8bf37780907292026q61805aadhd2019eae77739c47@mail.gmail.com","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"Thadeu Lima de Souza Cascardo","fromEmail":"cascardo@holoscopio.com","sentAt":"2009-07-30T15:44:47Z","receivedAt":"2009-07-30T15:44:47Z","isPatch":true,"sender":{"key":"cascardo@holoscopio.com","avatar":null},"body":"On Thu, Jul 30, 2009 at 12:26:14AM -0300, André Goddard Rosa wrote:\n> git gui uses 'po' at http://repo.or.cz/w/git-gui/git-gui-i18n.git to\n> handle all translations, including Brazilian Portuguese.\n> \n\nBut do they use it for Documentation? It doesn't seem so. po4a seems to\nbe a reasonable choice, which, in the end, means po too. But it would be\ninteresting to gather others experiences in keeping Documentation\ntranslations updated, not only software strings.\n\n> In the meantime, I've made some translation improvements over Thadeu's\n> translation work, fixing some typos overall. I'll send it as a\n> separate patch.\n> \n> @Thadeu: would you please double check it and perhaps add your Acked-by?\n> \n\nIt seems OK, but for three fixes as I've sent before. Would you mind\nre-sending them?\n\n> Thanks,\n> Andre\n\nRegards,\nCascardo.\n"},{"id":"119182","messageId":"b8bf37780907301042p4ed4c3e9x85e76ab04ca12696@mail.gmail.com","threadId":"19963","inReplyTo":"20090730154446.GD1727@vespa.holoscopio.com","subject":"Re: [PATCH] Translate the tutorial to Brazillian Portuguese.","fromName":"André Goddard Rosa","fromEmail":"andre.goddard@gmail.com","sentAt":"2009-07-30T17:42:25Z","receivedAt":"2009-07-30T17:42:25Z","isPatch":true,"sender":{"key":"andre.goddard@gmail.com","avatar":null},"body":"On 7/30/09, Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> wrote:\n> On Thu, Jul 30, 2009 at 12:26:14AM -0300, André Goddard Rosa wrote:\n>> git gui uses 'po' at http://repo.or.cz/w/git-gui/git-gui-i18n.git to\n>> handle all translations, including Brazilian Portuguese.\n>>\n>\n> But do they use it for Documentation? It doesn't seem so. po4a seems to\n> be a reasonable choice, which, in the end, means po too. But it would be\n> interesting to gather others experiences in keeping Documentation\n> translations updated, not only software strings.\n\nSure, that's what po4a is meant for.\n\n>> @Thadeu: would you please double check it and perhaps add your Acked-by?\n>>\n>\n> It seems OK, but for three fixes as I've sent before. Would you mind\n> re-sending them?\n\nI've sent it including the contributions/fixes from you and Carlos.\n\nThanks,\nAndre\n"}]}