On Thu, Jul 30, 2009 at 02:31:08PM -0300, André Goddard Rosa wrote: > From 02eb3045e4f1415528f8c07f6c9bafb0beb8c8cc Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Andr=C3=A9=20Goddard=20Rosa?= <andre.goddard@xxxxxxxxx> > Date: Thu, 30 Jul 2009 14:20:02 -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> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxx> > Signed-off-by: Carlos R. Mafra <crmafra2@xxxxxxxxx> > [Included extra fixes from Thadeu and Carlos as well] > --- > Documentation/pt_BR/gittutorial.txt | 144 +++++++++++++++++------------------ > 1 files changed, 70 insertions(+), 74 deletions(-) > > diff --git a/Documentation/pt_BR/gittutorial.txt > b/Documentation/pt_BR/gittutorial.txt > index f368b1b..38fab57 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, > +Caso as mudanças não conflitam, está pronto. Se existirem conflitos, I think the time tense here should be changed if we change from "Se" to "Caso". I'd rather keep "Se ... conflitam". > 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 I like "cheap", instead of "efficient". "cheap" is in the primary documentation, so I'd rather keep it "baratos". > 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': > > ------------------------------------- > $ 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, > +Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um > +trabalho melhor de visualizar sua história. Por exemplo, > > ------------------------------------- > $ gitk --since="2 weeks ago" drivers/ > ------------------------------------- > > -permite você navegar em quaisquer commits desde as últimas duas semanas > -de commits que modificaram arquivos sob o diretório "drivers". (Nota: > +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 quiser 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 Linux que dependem fortemente de patches > enviados por email. > > * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma > forma de rastrear um bug é procurando pela história para encontrar o > - commit culpado. Git bisect pode ajudar a executar uma busca binária > - por esse commit. Ele é inteligente o bastante para executar uma > + 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 > -------- This is all caps in the original. The original mix style in these topics, using "SEE ALSO", "Next Steps" and "Exploring history" to give a few examples. > linkgit:gittutorial-2[7], > linkgit:gitcvs-migration[7], > -- > 1.6.4.388.gc1120 Regards, Cascardo.
Attachment:
signature.asc
Description: Digital signature