git
sudo apt-get install cvs
Descargar: cvs2svn usando el comando
svn export --username=guest http://cvs2svn.tigris.org/svn/cvs2svn/trunk cvs2svn-trunk

rsync -ai <URL-CVS> <PROJECT>

NOTA: <URL-CVS> será algo de la forma a.cvs.sourceforge.net::cvsroot/aopalliance/

cp ./cvs2svn-trunk/cvs2git-example.options ./cvs2git.options
vi cvs2git.options
Modificar:

run_options.set_project(
# The filesystem path to the part of the CVS repository (*not* a
# CVS working copy) that should be converted. This may be a
# subdirectory (i.e., a module) within a larger CVS repository.
r'test-data/main-cvsrepos',

por

run_options.set_project(
# The filesystem path to the part of the CVS repository (*not* a
# CVS working copy) that should be converted. This may be a
# subdirectory (i.e., a module) within a larger CVS repository.
r'<PROJECT>',

./cvs2svn-trunk/cvs2git --options=cvs2git.options --fallback-encoding utf-8
mkdir <PROJECT>-git
cd <PROJECT>-git
git init
cat ../cvs2git-tmp/git-{blob,dump}.dat | git fast-import
git log
git reset --hard
git remote add origin <URL-GIT>
git push -u origin --all
git push --tags

vía

Anuncios

git

  1. Clona tu fork:
    git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git
  2. Añade el remote del repositorio original a tu repositorio:
    cd into/cloned/fork-repo
    git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
    git fetch upstream
  3. Actualiza tu fork a partir del repo original para mantener actualizados sus cambios:
    git pull upstream master
  4. Sube tus cambios:
    git push

vía

git
git clone --bare <URL-GIT-OLD>
cd <PROJECT>

Comprueba que están bien los datos de todos los desarrolladores:
git shortlog -e -s -n

Corrige con el siguiente script la información que pudiera estar mal:

git-author-rewrite-multiple.sh
————–
#!/bin/sh

for email in user1@olddomain.com user2@olddomain.com
do
git filter-branch -f --env-filter '

OLD_EMAIL="'${email}'"
CORRECT_NAME="'${email%%@*}'"
CORRECT_EMAIL="'${email%%@*}'@newdomain.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags; echo "done for ${email}"

done
————–

git push --mirror <URL-GIT-NEW>
cd ..
rm -rf <PROJECT>

Algunos enlaces de interés
Duplicating a repository
list authors of a git repository including commit count and email
Changing author info

git
sudo apt-get install git-svn
Descargar: svn-migration-scripts.jar


java -jar svn-migration-scripts.jar authors <URL-SVN> > authors.txt
git svn clone --prefix="" --stdlayout --authors-file=authors.txt <URL-SVN>
cd <PROJECT>
java -Dfile.encoding=utf-8 -jar ../svn-migration-scripts.jar clean-git --force
git remote add origin <URL-GIT>
git push -u origin --all
git push --tags

vía

git

Usar múltiples cuentas con repositorios remotos puede resultar complicado.  En esta entrada explico cómo podemos conseguir que Git utilice la clave SSH correcta para el repositorio en el que estemos trabajando.

Creación de diferentes claves públicas

Para generar una clave nueva ejecutaremos el siguiente comando:

$ ssh-keygen -t rsa -C "your_email@youremail.com" -f "your_user_id_file"

La opción -C es un comentario para ayudar a identificar la clave.  La opción -f especifica el nombre del fichero.

En el ejemplo, crearemos 2 claves que debemos guardar en el directorio ~/.ssh/:

~/.ssh/id_rsa_user1
~/.ssh/id_rsa_user2

Una vez creadas, las añadiremos al anillo de claves del agente SSH de autentificación ejecutando los comandos:

$ ssh-add ~/.ssh/id_rsa_user1
$ ssh-add ~/.ssh/id_rsa_user2

NOTA: Podemos eliminar todas las claves anteriormente cacheadas mediante el comando:

$ ssh-add -D

Finalmente podemos comprobar las claves almacenadas mediante el comando:

$ ssh-add -l

Importación de la clave pública en GitHub

Debes importar la clave púbica generada anteriormente en su cuenta GitHub asociada.

Consulta la documentación de GitHub para ver cómo hacerlo.

Configuración de SSH

En el directorio ~/.ssh/ crearemos un fichero llamado config:

$ cd ~/.ssh/
$ touch config

He introduciremos un contenido similar a este:

#user1 account
Host github.com-user1
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_rsa_user1

#user2 account
Host github.com-user2
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_rsa_user2

Clona tu repositorio y modifica su configuración Git

Clona tu repositorio git

$ git clone git@github.com-user1:user1/your-repo-name.git

Si ya tenías una copia local será necesario que actualices el origin:

$ git remote set-url origin git@github.com-user1:user1/your-repo-name.git

Ahora ve al repositorio Git local que quieres configurar y ejecuta:

$ git config user.name "user1"
$ git config user.email "user1@example.com" 

o puedes tener tu configuración git global:

$ git config --global user.name "user1"
$ git config --global user.email "user1@example.com"

Repite el proceso con el otro usuario y su repositorio.

A partir de aquí, podemos usar el flujo normal para publicar nuestro código

$ git add .
$ git commit -m "your comments"
$ git push

vía

git
Si no entiendes las motivaciones que hay detrás del diseño de Git, eres candidato a vivir un mundo de penurias. Con suficiente empeño puedes forzar a Git a actuar del modo que tú crees que debería hacerlo en vez del modo en que él quiere hacerlo. Pero eso es como usar un destornillador como si fuera un martillo; hace el trabajo, pero lo hace mal, lleva más tiempo, y estropea el destornillador.

Lee el resto de esta entrada »

El Génesis de GIT

17/06/2013

Genesis GIT
La Creación de GIT

  • El primer día: el almacén (repository) y el árbol de trabajo (working tree)

    Soy joven, el mundo es maravilloso y tengo mucho tiempo libre.

    Tengo tanto tiempo, que decido que quiero escribir un libro. El proyecto en el que estoy trabajando en una modesta historia y explicación de todo, con el título provisional de “El Libro”. Tiene una tabla de contenido contenido.txt y un solo capítulo:

    .
    ├── capitulo1.txt
    └── contenido.txt

    Según empiezo a escribir, empiezo a pensar que debería llevar un control de mis cambios. Necesito algún tipo de sistema de control de versiones. ¿Cómo de complicado puede ser esto?

    Lee el resto de esta entrada »

A %d blogueros les gusta esto: