Re: [PATCH] Fix typos on pt_BR/gittutorial.txt tra: msg#01897 git

Thanks a lot for the review. I will apply it to my tree with some little
changes.

On Thu, Jul 30, 2009 at 12:44:50AM -0300, AndrÃ Goddard Rosa wrote:
> From c11206cad8af0a3fbd55e5bf3cd74d3da144d843 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andr=C3=A9=20Goddard=20Rosa?= <andre.goddard@xxxxxxxxx>
> Date: Thu, 30 Jul 2009 00:35:17 -0300
> Subject: [PATCH] [PATCH] Fix typos on pt_BR/gittutorial.txt translation
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: AndrÃ Goddard Rosa <andre.goddard@xxxxxxxxx>
> ---
> Documentation/pt_BR/gittutorial.txt | 146
> +++++++++++++++++------------------
> 1 files changed, 71 insertions(+), 75 deletions(-)
>
> diff --git a/Documentation/pt_BR/gittutorial.txt
> b/Documentation/pt_BR/gittutorial.txt
> index f368b1b..531f310 100644
> --- a/Documentation/pt_BR/gittutorial.txt
> +++ b/Documentation/pt_BR/gittutorial.txt
> @@ -16,7 +16,7 @@ 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
> +Se, 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].
> @@ -37,9 +37,8 @@ $ 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
> -Ã:
> +Ã uma boa idÃia informar ao git 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"
> @@ -51,7 +50,7 @@ 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.
> +VocÃ pode colocÃ-lo sob controle de revisÃo git da seguinte forma:
>
> ------------------------------------------------
> $ tar xzf project.tar.gz
> @@ -76,7 +75,7 @@ $ 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
> +chama de "index" ou Ãndice. VocÃ pode armazenar permanentemente o
> conteÃdo do Ãndice no repositÃrio com 'git-commit':
>
> ------------------------------------------------
> @@ -142,7 +141,7 @@ 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
> +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.
>
> @@ -150,7 +149,7 @@ 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
> +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
> @@ -183,7 +182,7 @@ Gerenciando "branches"/ramos
> -----------------
>
> Um simples repositÃrio git pode manter mÃltiplos ramos de
> -desenvolvimento. Para criar um novo ramo chamado "experimental", use
> +desenvolvimento. Para criar um novo ramo chamado "experimental", use
>
> ------------------------------------------------
> $ git branch experimental
> @@ -203,14 +202,14 @@ vocÃ vai obter uma lista de todos os ramos existentes:
> ------------------------------------------------
>
> 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
> +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
> +para mudar para o ramo experimental. Agora edite um arquivo, grave a
> mudanÃa, e mude de volta para o ramo master:
>
> ------------------------------------------------
> @@ -230,14 +229,14 @@ $ 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
> +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,
> +Se as mudanÃas nÃo conflitam, estÃ pronto. Se existirem conflitos,
> marcadores serÃo deixados nos arquivos problemÃticos exibindo o
> conflito;
>
> @@ -245,7 +244,7 @@ conflito;
> $ git diff
> ------------------------------------------------
>
> -vai exibir isto. ApÃs vocÃ editar os arquivos para resolver os
> +vai exibir isto. ApÃs vocÃ editar os arquivos para resolver os
> conflitos,
>
> ------------------------------------------------
> @@ -273,10 +272,10 @@ Se vocÃ desenvolve em um ramo ideia-louca, e se
> arrepende, vocÃ pode
> sempre remover o ramo com
>
> -------------------------------------
> -$ git branch -D crazy-idea
> +$ git branch -D ideia-louca
> -------------------------------------
>
> -Ramos sÃo baratos e fÃceis, entÃo isto Ã uma boa maneira de experimentar
> +Ramos sÃo eficientes e fÃceis, entÃo isto Ã uma boa maneira de experimentar
> alguma coisa.
>
> Usando git para colaboraÃÃo
> @@ -293,7 +292,7 @@ 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
> +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:
> @@ -305,7 +304,7 @@ bob$ git commit -a
> ------------------------------------------------
>
> Quanto estÃ pronto, ele diz a Alice para puxar as mudanÃas do
> -repositÃrio em /home/bob/myrepo. Ela o faz com:
> +repositÃrio em /home/bob/myrepo. Ela o faz com:
>
> ------------------------------------------------
> alice$ cd /home/alice/project
> @@ -314,14 +313,14 @@ 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
> +precisar corrigir manualmente quaisquer 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
> +gravadas antes de iniciar este "pull". Se o trabalho de Bob 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
> @@ -341,18 +340,18 @@ 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.
> +alcanÃÃvel de FETCH_HEAD mas exclua tudo o que Ã alcanÃÃvel de HEAD.
> +Alice 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
> +Se Alice quer visualizar o que Bob fez desde que suas histÃrias se
> 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'.
> +Isto usa a mesma notaÃÃo de intervalo 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:
> @@ -361,23 +360,21 @@ 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".
> +Isto significa "mostre tudo que Ã alcanÃÃvel de qualquer um deles, mas
> +exclua tudo que Ã alcanÃÃvel a partir de ambos".
>
> 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
> +ApÃ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
> +Quando 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:
>
> ------------------------------------------------
> @@ -394,7 +391,7 @@ 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:
> +armazenado em um ramo remoto, neste caso `bob/master`. EntÃo, apÃs isso:
>
> -------------------------------------
> alice$ git log -p master..bob/master
> @@ -417,7 +414,7 @@ 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.
> +mais foi passado na linha de comando.
>
> Depois, Bob pode atualizar seu repositÃrio com as Ãltimas mudanÃas de
> Alice, usando
> @@ -428,7 +425,7 @@ 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
> +repositÃrio na configuraÃÃo do mesmo, e essa localizaÃÃo Ã usada
> para puxar:
>
> -------------------------------------
> @@ -459,15 +456,15 @@ 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].
> +repositÃrio central para o qual 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
> +interrelacionados. NÃs jÃ vimos que o comando 'git-log' pode listar
> +esses commits. Note que a primeira linha de cada entrada no log tambÃm
> dÃ o nome para o commit:
>
> -------------------------------------
> @@ -486,9 +483,9 @@ 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:
> +Mas hÃ outras formas de se referir aos commits. VocÃ pode usar qualquer
> +parte inicial do nome que seja longo o bastante para identificar
> +unicamente o commit:
>
> -------------------------------------
> $ git show c82a22c39c # os primeiros caracteres do nome sÃo o bastante
> @@ -497,7 +494,7 @@ $ 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
> +Todo commit normalmente tem um commit "pai" que aponta para o estado
> anterior do projeto:
>
> -------------------------------------
> @@ -513,19 +510,19 @@ $ 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
> +VocÃ tambÃm pode dar aos commits nomes Ã sua escolha; apÃs executar
>
> -------------------------------------
> $ git tag v2.5 1b2e1d63ff
> -------------------------------------
>
> -vocÃ pode se referir a 1b2e1d63ff pelo nome "v2.5". Se vocÃ pretende
> +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
> +uma versÃo de lanÃamento), vocÃ deveria 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:
> +quaisquer desses nomes. Por exemplo:
>
> -------------------------------------
> $ git diff v2.5 HEAD # compara o HEAD atual com v2.5
> @@ -537,8 +534,8 @@ $ git reset --hard HEAD^ # reseta seu ramo atual e
> seu diretÃrio de
>
> 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
> +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
> @@ -551,10 +548,10 @@ projeto, entÃo
> $ git grep "hello" v2.5
> -------------------------------------
>
> -procura por todas as ocorreÃncias de "hello" em v2.5.
> +procura por todas as ocorrÃ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
> +quaisquer dos arquivos que ele gerencia no diretÃrio corrente. EntÃo
>
> -------------------------------------
> $ git grep "hello"
> @@ -564,8 +561,7 @@ $ git grep "hello"
> 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':
> +ser especificado de vÃrias formas. Aqui estÃo alguns exemplos com 'git-log':

"vÃrias", not "vÃrias"

>
> -------------------------------------
> $ git log v2.5..v2.6 # commits entre v2.5 e v2.6
> @@ -584,7 +580,7 @@ comum algum tempo atrÃs, entÃo
> $ git log stable..master
> -------------------------------------
>
> -irÃ listas os commits feitos no ramo "master" mas nÃo no ramo
> +irÃ listar os commits feitos no ramo "master" mas nÃo no ramo
> "stable", enquanto
>
> -------------------------------------
> @@ -594,26 +590,26 @@ $ git log master..stable
> irÃ listar a lista de commits feitos no ramo "stable" mas nÃo no ramo
> "master".
>
> -O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em
> +O comando 'git-log' tem uma fraqueza: 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.
> +apresenta essas mudanÃas Ã irrelevante.
>
> -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,
> +A maioria dos projetos com mÃltiplos contribuidores (como o kernel do
> +linux, ou o prÃprio git) tem unificaÃÃes frequentes, e 'gitk' faz um
> +trabalho melhor de visualizar sua histÃria. Por exemplo,

Sorry, but I could never accept "kernel do linux". I am deeply against
this naming. It's "o kernel linux". It's like saying "kernel from linux"
instead of "the linux kernel".

>
> -------------------------------------
> $ 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:
> +permite a 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
> +Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirÃo
> +tambÃm, opcionalmente, preceder qualquer nome de arquivo por um
> commit, para especificar uma versÃo particular do arquivo:
>
> -------------------------------------
> @@ -630,33 +626,33 @@ 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
> +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,
> + * O arquivo de Ãndice Ã 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.
> + armazenar as vÃrias Ãrvores envolvidas em uma unificaÃÃo.
>
> -Parte dois deste tutorial explica a base de objetos, o arquivo de
> +A 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:
> +Se vocÃ nÃo quer continuar com o tutorial agora nesse momento, algumas
> +outras digressÃ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
> + sÃries de commits em patches para email, e vice-versa, Ãteis para
> + projetos como o kernel do linux que dependem fortemente de patches

Again!

> 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
> + 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.
>
> @@ -664,7 +660,7 @@ que podem ser interessantes neste ponto sÃo:
>
> * linkgit:gitcvs-migration[7]: Git para usuÃrios de CVS.
>
> -Veja TambÃm
> +Veja tambÃm
> --------
> linkgit:gittutorial-2[7],
> linkgit:gitcvs-migration[7],
> --
> 1.6.4.373.gc2651

While I can't help right now in the translation setup with po4a, I will
publish this in a tree of my own. It will be at
http://git.holoscopio.com/cascardo/git.git/, most likely.

Regards,
Cascardo.

signature.asc
Description: Digital signature

Re: [PATCH] Fix typos on pt_BR/gittutorial.txt translation: msg#01897

git