Archive

Posts Tagged ‘git’

Como ignorar los cambios de permisos (chmod) en Git

October 23, 2014 1 comment

Por si os preguntais alguna vez como evitar que Git registre los cambios de permisos o de “modo” de los archivos, aquí va una pequeña explicación que debería ayudaros.

La respuesta corta, como indicado en un post interesante de Stackoverflow, es de posicionarse dentro de la carpeta del repositorio Git local, en línea de comando, y lanzar:

git config core.fileMode false

Si se desea hacer esto una sola vez (para un solo comando) en vez de configurarlo para todos los commits futuros, hay que lanzar el comando:

git -c core.fileMode=false diff

Si ha cambio desea cambiarlo de una sola vez para *todos* sus repositorios, hay que hacer:

git config --global core.filemode false

o

git config --add --global core.filemode false

Luego, si desea retroceder algun cambio de permisos (para archivos y carpetas sucesivamente):

git diff --summary | grep --color 'mode change 100755 => 100644' \
 | cut -d' ' -f7- | xargs -d'\n' chmod +x
git diff --summary | grep --color 'mode change 100644 => 100755' \
 | cut -d' ' -f7- | xargs -d'\n' chmod -x

Este artículo es una mera traducción resumida del post en Stackoverflow, así que si quereis más detalles, seguid el enlace de arriba.

Categories: Best practices, desarrollo, Spanish Tags: ,

Git: Agent admitted failure to sign using the key

January 23, 2014 Leave a comment

Just as an internal note, if you get the following error trying to pull or push to a git repo:

“Agent admitted failure to sign using the key”

Your issue might be due to simply not having an identity defined in SSH. Simply use the “ssh-add” command to fix it.

Categories: English, Techie Tags: ,

Creating multiple git forks using upstream branches

December 26, 2013 Leave a comment

Working with Git is… complex. It’s not that it’s from another world, and the complexity is probably worth it considering the crazy things it allows you to do, but sometimes it’s just mind-bloggingly complex to understand how to do things right.

Recently, we’ve had to manage a series of projects with changes that cannot be applied directly to our original Git repository on Github, so we decided, after giving it some thought, to make several forks of the project (instead of branches), to manage more clearly permissions and the real intentions behind each of the forks.

This would allow us a few important things:

  • define precisely permissions based on the repository
  • use the repository to pull changes directly on our servers
  • have some level of local customization on each server, using local commits (and subsequent merges)
  • keep easy track of the changes that have been made on requests from some of our “customers” (they’re not necessarily commercial customers – sometimes they’re just users who decided to go crazy and show us what they can do, and we want to show that in public)

To do that, we need to fork our project (chamilo/chamilo-lms) several times over.

So the first problem is: you cannot fork the same project twice with the same user.
Adrian Short (@adrianshort) kind of solved that issue in his blog article, saying that you can just do the fork manually, creating an empty repo on Github and filling it with a copy of the main repo, then adding the origin remote manually.

Even though that works, the Github page (starting from the second fork with the same user) will *not* indicate it has been forked from chamilo/chamilo-lms: you’ll have to issue the
git remote -v
command to see that the upstream is correct.

The second problem is that the article doesn’t dive into the details of branch-level forks, so this article intends to solve that particular missing detail, and in that respect, the Github help is definitely useful. Check Syncing a fork help page if you want the crunchy details.

To make it short, there are 3 issues here:

  • fetching the branches from the original repo (upstream)
  • getting the desired branch to be checked out into your local repo
  • defining that, from now on, you want to work on your repo as a fork of that specific branch in upstream (to be able to sync with it later on)

The complete procedure then, considering my personal account (ywarnier) and the original chamilo/chamilo-lms project on Github, with the intention to work on branch 1.9.x, would look like this:


git clone git@github.com:chamilo/chamilo-lms
git remote -v
git remote rename origin upstream

(here you have to create the “chamilo-lms-fork1” repo by hand in your Git account)

git remote add origin git@github.com:ywarnier/chamilo-lms-fork1.git
git remote -v
git push -u origin master
git branch -va
git fetch upstream
git branch -va
git checkout --track remotes/upstream/1.9.x

This should get you up and kicking with your multiple forks in a relatively short time, hopefully!

Git vs Mercurial (Hg)

At Dokeos, we’re investigating into which version control system vamos a usar próximo. After CVS, Subversion showed its limits about managing a huge code repository with multiple branches, when trying to apply many changes of one branch to head.

The two most interesting systems remaining are Git and Mercurial. Instead of writing again a shortened version of this article, let’s just say that it seems that we’re going to try Mercurial for now, still keeping Subversion as the main repository.

Cómo clonar un enorme repositorio svn desde git

January 30, 2009 1 comment

git es un manejador de versiones distribuido bastante interesante, que tiene una interfaz con Subversion llamada git-svn.

git

git

Si están en un sistema Debian o uno de sus sitemas derivados, instalarlo es sencillo:

apt-get install git-svn

Para clonar un repositorio svn completo es necesario especificar qué carpetas son el tronco, las ramas y las etiquetas, de modo que git pueda identificarlas.

Así que para clonar un repositorio svn en teoría sólo se necesita hacer lo que dice el manual:

git svn clone http://svn.example.com/project -T trunk -b branches -t tags

Sin embargo, lo que hace git-svn clone es recabar cada uno de los commits realizados en el repositorio svn para almacenarlos en revisiones locales, como es natural pensar. Y justamente eso hace que sea muy costoso clonar un repositorio de un proyecto con muchos commits, por ejemplo uno de 18092 commits :D.

El problema es muy pequeño: ¿qué pasa si por alguna razón se pierde la conexión en el commit 15000? ¿se necesita rehacer la descarga? (notar que esta descarga podría demorar más o menos 1 día según la velocidad de conexión con el servidor svn, velocidad de PC local, etc)

La respuesta es no felizmente :D

Cuando se están descargando las revisiones de subversion sólo se escribe el índice y no el árbol de archivos y carpetas, así que no encontrarán nada en el directorio que están clonando excepto la carpeta .git.

Luego que se haya cortado la descarga lo que tenemos que hacer es:

  • reescribir nuestra rama master(a la que apunta por defecto HEAD), a la última revisión obtenida(es sencillo ver cuál es el último hash en la salida del comando), esto es: si el hash es b977ed6c9b4a1c758b6c230d8f8e507ce78e074e:

echo b977ed6c9b4a1c758b6c230d8f8e507ce78e074e > .git/refs/heads/master

  • Luego de eso, ya sólo nos queda forzar quedarnos en la última versión descargada:

git reset --hard

  • Y cuando querramos seguir decargando el repo, pues actualizamos normalmente:

git svn rebase --all

%d bloggers like this: