Commit parcial no Git

Sabe quando você quer fazer o commit de apenas parte de um arquivo?
Usando o parâmetro -i o git irá executar o add no modelo interativo.

No exemplo irei usar o arquivo vimrc.

git add <vimrc> -i

Como resposta ele irá apresentar os comandos disponíveis:

           staged     unstaged path
  1:    unchanged       +15/-4 vimrc

*** Commands ***
  1: status	  2: update	  3: revert	  4: add untracked
  5: patch	  6: diff	  7: quit	  8: help
What now>

Escolhendo o comando 5, ele irá perguntar qual arquivo você quer adicionar, parcialmente, no stage.

           staged     unstaged path
  1:    unchanged       +15/-4 vimrc
Patch update>>

Selecione o arquivo que você irá adicionar, no stage, informando o número do arquivo. No caso, só tenho um arquivo para adicionar.
Selecionado o arquivo o git apresenta a primeira diferença do arquivo e pergunta o que fazer com ela.

diff --git a/vimrc b/vimrc
index 5199dfd..aa2b489 100644
--- a/vimrc
+++ b/vimrc
@@ -17,15 +17,16 @@ Bundle 'scrooloose/nerdcommenter.git'
 Bundle 'scrooloose/nerdtree.git'
 Bundle 'kien/ctrlp.vim'
 Bundle 'tpope/vim-endwise.git'
-Bundle 'claco/jasmine.vim.git'
-Bundle 'groenewege/vim-less'
+"Bundle 'claco/jasmine.vim.git'
+"Bundle 'groenewege/vim-less'
 Bundle 'tpope/vim-ragtag.git'
-Bundle 'tpope/vim-rails.git'
 Bundle 'vim-ruby/vim-ruby.git'
+Bundle 'tpope/vim-rails.git'
+"Bundle 'm2ym/rsense'
 "Bundle 'tpope/vim-pathogen.git'
+"Bundle 'm2ym/rsense'
 " ==========================================
 
-
 filetype on           " Enable filetype detection
 filetype plugin on    " Enable filetype-specific plugins
 filetype indent on    " Enable filetype-specific indenting
Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]?

Para:
– n: ignorar esta diferença e ir para a próxima e vai para a próxima diferença
– y: adiciona a diferença no stage e vai para a próxima diferença
– q: termina a interação com esse arquivo

Ao final das diferenças no arquivo ele volta para o estado inicial do add. Use 7 para sair.

Feito isso, se você não tiver adicionado todas as diferenças no stage, o git status irá informar que o arquivo vimrc está no stage e está modificado.

Pronto!

Agora temos apenas parte do arquivo adicionado no stage, usando o commit interativo do git.

Fonte: http://git-scm.com/book/en/Git-Tools-Interactive-Staging

Git para SVN de forma manual

Tem esse projeto que eu comecei usando o Git, mas tenho que entregar em um SVN.

Daí para não bagunçar o checkout que fiz do SVN resolvi continuar usando o Git e copiar os arquivos para o diretório onde está o checkout do SVN.

Para saber quais arquivos tenho que copiar uso o

git diff <id_do_commit_que_ainda_não_copiei> --name-only

Para copiar os arquivos listados eu uso o xargs* com cp.

xargs -I {} cp {} ../projeto_no_svn/{}

Assim, para cada arquivo listado pelo git diff, o xargs vai executar um comando:

cp diretorio/arquivo.algumacoisa ../projeto_no_svn/diretorio/arquivo.algumacoisa

O comando completo fica:

git diff <id_do_commit_que_ainda_não_copiei> --name-only | xargs -I {} cp {} ../projeto_no_svn/{}

* Fonte: http://www.cyberciti.biz/faq/linux-unix-bsd-xargs-construct-argument-lists-utility/

Configurar ambiente de QA e Produção no Heroku.

Estou com um projeto pessoal no Heroku.
Recentemente surgiu a necessidade de criar um ambiente para demonstração. Como todo meu desenvolvimento está sendo feito no master tenho que informar qual o branch remoto que desejo fazer o push.

Criar o branch de qa e produção:

git checkout -b qa
git remote add heroku-qa git@heroku.com:appname-qa.git
git fetch heroku-qa
git branch qa --set-upstream-to=heroku-qa/master

git checkout master
git branch production --set-upstream-to=heroku-production/master

Isso resolve a questão de qual código está em cada ambiente. Mas, me gera o problema de, sempre que quero fazer um push preciso usar:

git push heroku-qa HEAD:master

Para resolver isso, mudo o local de onde o git vai procurar no servidor remoto. Ao invés de procurar um branch, remoto, com o mesmo nome do local, ele usa o branch configurado como upstream.

git config push.default upstream

Mais informações sobre o destino do push em: http://git-scm.com/docs/git-config.html:

push.default
Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line.[…]

Agora, já posso fazer apenas um git push, que o git sabe para qual branch remoto mandar, de acordo com o branch local.

Gostaria de saber mais?
http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/
http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0

Recuperando a lista de commiters do CVS

Alguns dos projetos, em que estou trabalhando, ficam no CVS. Estou tentando convertê-lo para o Maven sem causar impacto no trabalho dos outros desenvolvedores da equipe. Para isso preciso conseguir fazer o trabalho off-line e só publicar para os outros quando já estiver pronto.

Isso me levou a uma cruzada pessoal para mostrar as vantagens de se usar um Git da vida. No momento, consegui, junto com outros desenvolvedores, adotar o Git em uns projetos mais novos da equipe.

Para que eu consiga usar o Git neste projeto, preciso conseguir fazer uma importação do repositório. E, nesta importação, converter os nomes dos autores do commit para o formato do git.

Minha primeira dificuldade foi conseguir a lista de autores do CVS. Na falta de uma ferramenta melhor, fui para o Terminal:
export CVS_ROOT=:pserver:nome_usuario_cvs@servidor:path_repo
cvs login
cvs checkout MeuProjeto
cvs log > dump_do_log.txt
less dump_do_log.txt | grep "author: ." | awk '{sub(/\;/,"= <>",$5); print $5}' | sort -u > autores_do_meuprojeto.txt

No final eu terei um arquivo assim:
cvs_acdesouza= <>

Agora vem o trabalho de mapear os nomes e emails. Mas isso vai ter que ser manual 😦

Agradeço aos autores dos tutoriais e fóruns que me ajudaram:
Tutorial do Awk
Ordenar a lista de usuários e remover as entradas duplicadas;
Remover o ; no nome do usuário.

Tutorial Git

Algum tempo atrás eu estava estudando os SCMs distribuídos mais conhecidos: Git, Hg, Bazaar. E, na época tinha me decidido pelo Bazaar.

Claro, que o mais simples(Bazaar) de usar, instalar no Windows e com ferramenta gráfica não tem metade da aceitação que o Git apresenta. Atribuo todo o sucesso do Git ao GitHub. Ele é imbatível.

Portanto, me vi obrigado a aprender sobre o Git e lendo o Reddit, hoje, encontrei isso: A guided tour that walks through the fundamentals of Git

Poxa! Custava ter encontrado esse tutorial antes?


[],
AC