Edit Mantenimiento de Git de sico

Title:

Last edited: 10:22:12 am on 3 March 2022 by 3.0.1.3

<a href="http://3.0.1.46:8000/HowTo/218">Ir al HOWTO de Git</a>
+^ _@
_
<tt>Thursday, 24 February 2022, 11:18:44 am</tt>
Migro los repositorios desde gitolite a gitea Usando *estas instrucciones (comentario del 4 de enero de 2018)>https://gist.github.com/joepie91/2ff74545f079352c740a*, el *api usage>https://docs.gitea.io/en-us/api-usage/* y el *config cheat sheet>https://docs.gitea.io/en-us/api-usage/*. Además se usan *las instrucciones que ponen en este issue>https://github.com/go-gitea/gitea/issues/9156*. Y *este otro howto para migrar repositorios a gitea>https://jpmens.net/2019/04/15/i-mirror-my-github-repositories-to-gitea/* y *este otro para aspectos puntuales de configuración (p.ej. SSL)>https://charlesreid1.com/wiki/Gitea#Using_Self-Signed_Cert*.

1. Se genera un token en el usuario gitea (http:3.0.1.45:3000 , user &gt; settings &gt; applications) con el nombre "gitolite2gitea_184hs181ak1"

2. Se comprueba que el userid es el correcto (user &gt; site administration &gt; user accounts). En el script de abajo se usa el userid 1, que debe de coincidir con el userid "gitea" que es el de admnistrador que hemos creado antes.

2. Se copian los repositorios desde chibiko a alejandia para que el gitea pueda acceder a ellos:
En alejandria, como root
<code>
mkdir -p /var/lib/gitolite
chown git:git /var/lib/gitolite
</code>
En alejandria, como git
(se copia el id_rsa y el id_rsa.pub del usuario metro al usuario git)
En chibiko, como root:
(se añade el id_rsa.pub del paso anterior al authorized_keys de root@3.0.1.44)
En alejandria, como git:
<code>
cd /var/lib/gitolite
ssh root@3.0.1.44 "cd /var/lib/gitolite && tar -cf - repositories | gzip -1" | tar -xzf -
# Para actualizarlos en un momento posterior, ese usa la siguiente línea
rsync -av root@3.0.1.44:/var/lib/gitolite/repositories .
</code>

3. Accedo a http://3.0.1.45:300, entro como gitea:gitea, y abro *http://3.0.1.34:3000/apli/swagger*, pincho "authorize" y en AuthorizationHeaderToken pongo "token gitolite2gitea_184hs181ak1" y pulso authorize.

3. En alejandria, como git, se hace lo siguiente:
<code>
cd /var/lib/gitolite/repositories
rm -f /tmp/migrate.sh
cat > /tmp/migrate.sh <<'EOF'
#!/bin/sh

HOSTNAME="3.0.1.45"
BASEPATH="/var/lib/gitolite/repositories"
USERID=1

while read REPO; do
 REPONAME=`echo "$REPO" | sed "s/\.git\$//"`
 curl -H 'Content-Type: application/json' \
 -H 'Authorization: token gitolite2gitea_184hs181ak1 ' \
 -d '{"clone_addr": "'$BASEPATH'/'$REPO'", "uid": '$USERID', "repo_name": "'$REPONAME'"}' \
 -X POST http://$HOSTNAME:3000/api/v1/repos/migrate
done
EOF
chmod a+x /tmp/migrate.sh
ls -1 | grep "\.git\$" | grep -v gitolite-admin | /tmp/migrate.sh
</code>
_
<tt>Tuesday, 22 February 2022, 11:47:51 am</tt>
Se instala "alejandria" (3.0.1.45, Devuan 4.0 "Chimaera") como nuevo servidor git, usando gitea Se siguen las *instrucciones oficiales del gitea>https://docs.gitea.io/en-us/install-from-binary/*

En alejandria, como root:
<code>
apt-get install git nginx gpg postgresql
/etc/init.d/postgresql stop
cd /etc/postgresql/13/main/
sed -i "s/^.*listen_addresses = .*/listen_addresses = 'localhost, 3.0.1.45'/g" postgresql.conf
sed -i "s/^.*password_encryption = .*/password_encryption = scram-sha-256/g" postgresql.conf
/etc/init.d/postgresql start
su -c "psql" - postgres
CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'es_ES.UTF-8' LC_CTYPE 'es_ES.UTF-8';
\q
sed -i '/local.*all.*postgres.*peer/alocal giteadb gitea scram-sha-256' pg_hba.conf
/etc/init.d/postgresql restart
# Comprobamos que el usuario y la BBDD están bien generados
psql -U gitea -d giteadb
# password: gitea
\q
cd /usr/local/bin/
wget -O gitea https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
wget https://dl.gitea.io/gitea/1.16.3/gitea-1.16.3-linux-amd64.asc
gpg --verify gitea-1.16.3-linux-amd64.asc gitea
adduser \
 --system \
 --shell /bin/bash \
 --gecos 'Git Version Control' \
 --group \
 --disabled-password \
 --home /home/git \
 git
mkdir /etc/gitea
chown root:git /etc/gitea
chmod 770 /etc/gitea
cat >/etc/init.d/gitea <<'EOF'
#!/bin/sh
#
# Init script for gitea
#
# Parts copied from a start script for virtlogd by agx@sigxcpu.org
#
### BEGIN INIT INFO
# Provides: gitea
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start the gitea daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
export PATH
DAEMON=/usr/local/bin/gitea
NAME=gitea
DESC="gitea daemon"

test -x $DAEMON || exit 0
. /lib/lsb/init-functions

PIDFILE=/var/run/$NAME.pid
DODTIME=1                   # Time to wait for the server to die, in seconds
GITEA_WORK_DIR=/home/git/gitea
export GITEA_WORK_DIR
GITEA_USER=git
GITEA_ARGS="-c /etc/gitea/app.ini -q --pid $PIDFILE"

# Include libvirtd defaults if available
if [ -f /etc/default/gitea ] ; then
        . /etc/default/gitea
fi

running_pid()
{
    # Check if a given process pid's cmdline matches a given name
    pid=$1
    name=$2
    [ -z "$pid" ] && return 1
    [ ! -d /proc/$pid ] &&  return 1
    cmd=`cat /proc/$pid/cmdline | tr "\000" "\n"|head -n 1 |cut -d : -f 1`
    # Is this the expected child?
    [ "$cmd" != "$name" ] &&  return 1
    return 0
}

running()
{
# Check if the process is running looking at /proc
# (works for all users)
    # No pidfile, probably no daemon present
    [ ! -f "$PIDFILE" ] && return 1
    # Obtain the pid and check it against the binary name
    pid=`cat $PIDFILE`
    running_pid $pid $DAEMON || return 1
    return 0
}

case "$1" in
        start)
	    log_daemon_msg "Starting $DESC" "$NAME"
	    if running ;  then
	        log_progress_msg "already running"
	        log_end_msg 0
	        exit 0
	    fi
	    rm -f $PIDFILE
	    touch $PIDFILE
	    chown git:git $PIDFILE
	    start-stop-daemon --start --quiet --pidfile $PIDFILE --chuid git \
                        --background --exec $DAEMON -- $GITEA_ARGS
	    sleep 0.2
	    if running; then
	        log_end_msg 0
	    else
	        log_end_msg 1
	    fi
            ;;
        start-debug)
            log_daemon_msg "Starting $DESC in foreground" "$NAME"
            if running ;  then
                log_progress_msg "already running"
                log_end_msg 0
                exit 0
            fi
            rm -f $PIDFILE
            touch $PIDFILE
            chown git:git $PIDFILE
            start-stop-daemon --start --quiet --pidfile $PIDFILE --chuid git \
                    --exec $DAEMON -- $(echo $GITEA_ARGS | sed "s/ -q / /g")
            sleep 0.2
            if running; then
                log_end_msg 0
            else
                log_end_msg 1
            fi
            ;;
	stop)
	    log_daemon_msg "Stopping $DESC" "$NAME"
	    if ! running ;  then
	        log_progress_msg "not running"
	        log_end_msg 0
	        exit 0
	    fi
	    start-stop-daemon --stop --quiet --pidfile $PIDFILE \
	                      --exec $DAEMON
	    log_end_msg 0
	    ;;
        restart)
	    $0 stop
	    $0 start
            ;;
        *)
            log_success_msg "Usage: gitea {start|start-debug|stop|restart}"
            log_success_msg "       start, stop or reload the gitea git server"
            return 1
            ;;
esac

exit 0
EOF
chmod a+x /etc/init.d/gitea
update-rc.d gitea defaults
/etc/init.d/gitea start
for i in repositories lfs log ; do mkdir -p /home/git/$i ; chown git:git /home/git/$i ; done
cd /home/git
su git
mkdir ssl
cd ssl
/usr/local/bin/gitea cert --host 3.0.1.45
exit
</code>

A continuación, se abre un navegador a la dirección *http://3.0.1.45:3000/* para terminar la configuración, y se elige (sólo indico los campos que cambian):
|Database type|postgres|
|password|gitea|
|database name|giteadb|
|site title|SICOSOFT Git Server|
|Repository Root Path|/home/git/repositories|
|Server Domain|3.0.1.45|
En optional settings, email:
|SMTP Host|3.0.1.124|
|Send email as|"Git de SICOSOFT" <dariorodriguez@sicosoft.es>|
En optional settings, Server and Third-Party Service Settings:
|Enable federated avatars|DESACTIVADO|
|Enable OpenID Sign In|DESACTIVADO|
|Hidden email domain|sicosoft.es|
En optional settings, Administrator Account Settings:
|Username|gitea|
|Password|gitea|
|Confirm password|gitea|
|email|dariorodriguez@sicosoft.es|

Y entonces se clica en INSTALL.

NOTA: Los usuarios hay que darlos de alta con el mismo nombre de usuario que el email de SICO para que funcione lo de "Hidden email domain".

Por último, una vez comprobado que el servidor gitea funciona en *http://3.0.1.45:3000*, se desactiva el acceso a escritura del fichero de configuración por parte del servidor web gitea:

(NOTA: ESTO ESTÁ SIN HACER)
En alejandria, como root:
<code>
chmod 750 /etc/gitea
chmod 440 etc/gitea/app.ini
/etc/init.d/gitea restart
</code>

Update 20220303 Cambio la versión del ejecutable del 1.16.0 al 1.16.3, tanto en alejandria como en las instrucciones de esta entrada.
_
<tt>Tuesday, 30 March 2021, 8:42:31 am</tt>
No funcionaba el git de chibiko desde salchicha (ni desde el propio chibiko) Resulta que estaba desinstalado el paquete gitolite. Aparte, todas las cosas del home de gitolite estaban como del usuario gitlog. Se ha hecho lo siguiente:

En chibiko como, root:
<code>
cd /var/lib/gitolite
find . -uid 115 -print | while read l ; do chown gitolite "$l" ; done
apt-get install gitolite
</code>
_
<tt>Monday, 20 January 2020, 9:50:13 am</tt>
El gitweb no está funcionando ahora mismo en chibiko, y el gitlist da un error He activalo el gitlist haciendo la redirección siguiente en chibiko como root:
<code>
cd /etc/apache2/mods-enabled
ln -s ../mods-available/rewrite.load .
echo 'Redirect "/gitweb/" "/gitlist/"' > gitweb
apache2ctl restart
</code>

Pero el gitlist da un error, que *según este thread>https://stackoverflow.com/questions/17156251/unexpected-character-in-input-ascii-92-state-1*, es porque necesita php5 version 5.4 o superior, y ahora tiene el 5.2.

TODO: compilar un "libapache2-mod-php5" con un php más moderno, así como el "php5", "php5-cgi" y "php5-common"

NOTA: seguramente también haya que compilar "apache2-mpm-prefork", "apache2-utils", "apache2.2-common", "libapache2-mod-authnz-external", "libapache2-mod-php5".
_
<tt>Saturday, 31 August 2013, 1:04:35 am</tt>
Desaparecían repositorios del gitweb al hacer un commit por culpa de no ser el apache ejecutado como usuario gitolite Me pasaba lo mismo que *en este post>http://stackoverflow.com/questions/5216008/the-project-disappear-from-gitweb-after-a-git-push*. Lo que he hecho ha sido lo siguiente, en chibiko, como root:
<code>
root@chibiko# /etc/init.d/apache2 stop
root@chibiko# sed -i "s/APACHE_RUN_USER=www-data/export APACHE_RUN_USER=gitolite/g" /etc/apache2/envvars
root@chibiko# /etc/init.d/apache2 restart
</code>
_
<tt>Friday, 15 February 2013, 7:22:06 pm</tt>
Uso de git en salchicha salchicha tiene un git muy antiguo (1.5.x), y eso hace que:
- salchicha no puede clonar repositorios vacíos

Para suplir eso, hay que hacer el primer commit desde orto sitio. metro@chibiko tiene permisos para todos los repositorios, y se aconseja hacerlo en él. Por ejemplo, para tctiserver se ha hecho de la siguiente manera:
<code>
metro@chibiko$ cd /tmp
metro@chibiko$ git clone git@chibiko:tctiserver tctiserver
metro@chibiko$ cd tctiserver/
metro#chibiko$ echo "tctiserver es el servidor de autentificacion de TCTI" > README
metro@chibiko$ git add -A
metro@chibiko$ git commit -m "Initial commit (README)"
metro@chibiko$ git push origin master
</code>

Lo del "<tt>git push origin master</tt>" es que el primer push se hace así en el git (para el resto ya vale lo del "<tt>git push</tt>" a secas, eso es porque los refs no están apuntando a master o algo así).

_
<tt>Friday, 15 February 2013, 5:32:20 pm</tt>
Actualizo gitolite a 3.2+ (git20130215) He hecho lo siguiente, en chibiko:

<code>
# cd /var/lib
# mv gitolite gitolite_g3.03
# mkdir -p gitolite/bin
# chown -R gitolite:gitolite gitolite
# cp /etc/skel/.* gitolite/
# chown gitolite:gitolite gitolite/.*
# su - gitolite
$ scp metro@localhost:.ssh/id_dsa.pub admin.pub
$ git clone git://github.com/sitaramc/gitolite
$ gitolite/install -to $HOME/bin
$ gitolite setup -pk admin.pub 
$ cd ~/repositories
$ mv ../../gitolite_g3.03/repositories/* .
$ for i in `find . -type l -name update` ; do rm $i ; ln -s /var/lib/gitolite/.gitolite/hooks/common/update $i ; done
$ exit
</code>

Los uid/groups estaban configurados de la siguiente manera:
=/etc/passwd
|<tt>gitolite:x:117:120:git repository hosting,,,:/var/lib/gitolite:/bin/bash git:x:117:120::/var/lib/gitolite:/bin/bash</tt>|
=/etc/group
|<tt>gitolite:x:120:www-data,gitdaemon git:x:1002:</tt>|

_
<tt>Thursday, 14 February 2013, 7:30:19 pm</tt>
Hay que cambiar un poco las scripts asistentes del Git Según *este thread del autor del gitolite>http://comments.gmane.org/gmane.comp.version-control.gitolite/1075*, la línea "<tt>repo nombrerepo</tt>" no es una declaración, sino que simplemente cambia el repositorio actual para las siguientes líneas "RW+ =...". Por eso no está creando los repositorios automáticamente.

<ul><li>Sistema "agresivo", con wildcards:</li></ul>
Según parece, lo que habría que hacer es algo parecido a
<table border=1><tr><td>
<code>
repo @all [a-zA-Z]..*
 C = dev1 dev2 dev3
 RW+ = dev1 dev2 dev3

# Repo specific permissions from here
repo RepoB
 RW = dev4 dev5
</code>
</td></tr></table>

Con eso los repositorios se generan "automáticamente" desde el cliente con un mero
= $ git ls-remote git@host:NewRepo

<ul><li>Una alternativa menos "agresiva" sería generar el conf de la siguiente manera:</li></ul>

<table border=1><tr><td>
<code>
@repos = RepoA
@repos = RepoB
@repos = RepoC

# Global permissions
repo @all
    RW+ = dev1 dev2 dev3

# Repo specific permissions from here
repo RepoB
 RW = dev4 dev5
</code>
</td></tr></table>

Con ambas soluciones, al editar el conf, el gitolite crea el repositorio.

NOTA Realmente eso está arreglado en el *gitolite 3.2>https://github.com/sitaramc/gitolite/commit/16f2d9b879516e6268fe8f12f930318f6916a42c*, pero nosotros tenemos instalado el 3.03... ¿se podría actualizar? ¿Cómo fuciona el gbp.conf de *aquí>https://github.com/mtelleria/gitolite3-debian-packaging* para generar un nuevo paquete? Supongo que es *siguiendo esta guía...>http://wiki.debian.org/PackagingWithGit*
_
<tt>Tuesday, 12 February 2013, 6:13:30 pm</tt>
Migración a gitolite 3 ("G3") Como para arreglar el problema de permisos hay que hacer un trabajo similar al de la reinstalación, aprovecho para migrar a gitolite 3 (¡¡¡inicialmente habíamos instalado gitolite 1!!!).
Documentos necesarios para la migración:
- *gitolite 3 debian packaging>https://github.com/mtelleria/gitolite3-debian-packaging*
- *debian bugs: gitolite 3 packaging integration request>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673867*
- *Installing/migrating gitolite>http://sitaramc.github.com/gitolite/install.html#migr*
- *Read first: migrating to g3>http://sitaramc.github.com/gitolite/migr.html*
- *Read first: pre-migration checklist>http://sitaramc.github.com/gitolite/g2migr.html*

Al final la "migración" la he hecho de la siguiente manera:
<code>
chibiko# cd /var/lib
chibiko# mv gitolite gitolite_g1
chibiko# cd /root/src.gitolite
chibiko# dpkg -i gitolite3_3.03-u1-06d3398-1ppa1_all.deb
chibiko# cp /home/metro/.ssh/id_dsa.pub /tmp/metro_chibiko.pub
chibiko# dpkg-reconfigure gitolite3
Cuando pregunta por la clave del administrador, poner "/tmp/metro_chibiko.pub" (sin las comillas).
chibiko# apt-get remove gitolite
chibiko# cd /var/lib/gitolite/repositories
chibiko# mv ../../gitolite_g1/repositories/* .
chibiko# for i in *.git ; do rm $i/hooks/update ; ln -s /var/lib/gitolite/.gitolite/hooks/common/update $i/hooks/update ; done
chibiko# ls -1 | grep -v "gitolite-admin\|testing" > ../projects.list
</code>

Después para poner otra vez los repositorios antiguos:
<code>
metro@chibiko$ mkdir t8
metro@chibiko$ cd t8
metro@chibiko$ git clone git@chibiko:gitolite-admin
metro@chibiko$ cd gitolite-admin/conf
metro@chibiko$ echo "" >> gitolite.conf
metro@chibiko$ ( cd /var/lib/gitolite/repositories && ls -1 ) | while read r ; do n=`echo $r | sed s/\.git//g` ; if ! grep $n gitolite.conf >/dev/null ; then (echo "repo $n" ; echo "") >> gitolite.conf ; fi ; done
metro@chibiko$ cd ..
metro@chibiko$ git add -A
metro@chibiko$ git commit -m "restored old repo"
metro@chibiko$ git push
</code>

</code>
_
<tt>Monday, 11 February 2013, 6:57:50 pm</tt>
Problemas con la configuración Parece que la script de permisos se ha "equivocado" y ha quitado los permisos a gitolite-admin para todos los usuario s(no se debería poder hacer eso). Al ir a arreglarme he he encontrado con este "troublesooting manual":
- *Gitolite: ssh troubleshooting and tips>http://sitaramc.github.com/gitolite/sts.html*

Y el HOWTO que me ha dado cómo solucionar mi problema es:
- *Help for emergencies: bypassing gitolite>http://sitaramc.github.com/gitolite/emergencies.html*
_
<tt>Thursday, 7 February 2013, 6:03:37 pm</tt>
Cómo sacar una versión antigua de un fichero del git Se puede seguir el ejemplo de *gitolite hosting>http://www.nineproductions.com/gitolite-hosting/*:

Buscamos el fihcero
=$ git log --name-only
Copiamos la versión actual del fihcero fuera del repositorio
=$ cp file ~/Desktop
Sacamos la versión antigua del fichero desde el git
= $ git checkout 389y5r8qfhhqwfhfujh file
_
<a name="20131117161743"><tt>Thursday, 17 January 2013, 4:17:43 pm</tt></a>
Añadir más usuarios para que puedan cambiar la configuración Se siguen *estas instrucciones>http://stackoverflow.com/questions/10843781/gitolite-adding-user-not-working-and-denied-by-fallthru-when-cloning-as-root* (sustituye el <tt>nuevo</tt> en itálicas por el nombre de tu máquina, p.ej. <tt>pepito</tt>):
1. Si no tienes claves dsa en el usuario al que quieres autorizar:
nuevo$ <tt>cd ~/.ssh</tt>
nuevo$ <tt>ssh-keygen -t dsa</tt>
nuevo$ <tt>scp id_dsa.pub metro@chibiko:/tmp/nuevo.pub</tt>
2. Se copia el id_dsa.pub a chibiko:gitolite-admin/keydir
metro@chibiko$ <tt>mkdir t5</tt>
metro@chibiko$ <tt>cd t5</tt>
metro@chibiko$ <tt>git clone git@chibiko:gitolite-admin</tt>
metro@chibiko$ <tt>cd gitolite-admin</tt>
metro@chibiko$ <tt>cp /tmp/nuevo.pub keydir</tt>
metro@chibiko$ <tt>sed -i "/gitolite-admin/aRW+ = nuevo" conf/gitolite.conf</tt>
metro@chibiko$ <tt>git add -A</tt>
metro@chibiko$ <tt>git commit -m "updated configuration"</tt>
metro@chibiko$ <tt>git push</tt>

_
<tt>Thursday, 27 September 2012, 7:50 pm</tt>
Copiar en read-only el repositorio git a un PC windows Primero se instala el wget para windows y el *activestate python 2.7>http://www.activestate.com/activepython*. Despues se hace lo siguiente:

Copiar el repositorio en un windows:

C:\Users\metro\Documents\repositorio>"\Program Files\GnuWin32\bin\wget.exe" -m -k http://3.0.1.44/gitweb/

Hacer que se pueda ver desde el Internet Explorer:

C:\Users\metro\Documents\repositorio\3.0.1.44\gitweb>\Python27\python.exe -m SimpleHTTPServer

En el Internet explorer hay que abrir la siguiente URL:
http://localhost:8000

_
<tt>Tuesday, 24 July 2012, 7:39:40 pm</tt>
Ya están importados los fuentes al repositorio de controlid con historia y changelog He actualizado la antrada anterior el el procedimiento que he utilizado finalmente.

Incluso se pueden consultar vía web:

*http://3.0.1.44/gitweb/?p=controlid.git;a=summary*

FALTA: incluir el repositorio de chibiko (&nbsp;<tt>/var/lib/gitolite/repositories/</tt>&nbsp;) al backup semanal.

A partir de ahora, cuando se hagan modificacione y se quiera poner una nueva "versión" en el repositorio, se harían los cambios como siempre en el directorio ControlId, y después como arcom en chibiko se "suben" al repositorio con:
<code>
$ cd /home/arcom/ControlId
$ git add -A
$ git commit -m "Comentario del commit"
$ git push
</code>

Como alternativa, se puede hacer el commit usando los datos del ControlId/ChangeLog utilizando la script commit-with-changelog.sh (el parámetro al commit-with-changelog.sh es la versión que se va a poner en loc comentarios al commit):

<code>
$ cd /home/arcom/ControlId
$ git add -A
$ ../commit-with-changelog.sh 1.7.8
$ git push
</code>

La script en cuestión es la siguiente:
= commit-with-changelog.sh
<table border=1><tr><td><code>
#!/bin/bash
export GIT_AUTHOR_IDENT="Guillermo Gonzalez <ggonzalez@sicosoft.es>"
export GIT_COMMITTER_IDENT="Guillermo Gonzalez <ggonzalez@sicosoft.es>"
cd /home/arcom
miversion=""
if [ "m$1" != "m" ] ; then
 miversion=".$1"
fi
midate=`date +%Y-%m-%d`
datedversion=$midate$miversion
rm -f /tmp/changelog
echo "$midate: version $datedversion" > /tmp/changelog
echo "" >> /tmp/changelog
if [ -e ControlId/ChangeLog ] ; then
 cat ControlId/ChangeLog | sed "0,/---/d" | sed "/---/,\$d" | sed '$d' >> /tmp/changelog
fi
git commit -F /tmp/changelog
</code></td></tr></table>

_
<tt>Friday, 20 July 2012, 7:59:14 pm</tt>
Se han importado los snapshots de controlid en el git 
(Update 20120724: simplificado el proceso y corregidas las scripts).

Para añadir un nuevo repositorio llamado controlid:
<code>
cd /home/arcom
git clone git@chibiko:gitolite-admin
cd gitolite-admin
echo " repo controlid" >> conf/gitolite.conf
echo " RW+ = id_dsa" >> conf/gitolite.conf
git add -A
git commit -m "updated configuration"
git push
</code>

NOTA: Si quisieras borrar un repositorio completamente, se puede hacer (como root) un "<tt>rm -rf /var/lib/gitolite/repositories/nombrerepositorio.git</tt>" y editar según el método anterior el "<tt>conf/gitolite.conf</tt>"para quitar las dos líneas que hacen referencia al repositorio. Para recrearlo rehacer los pasos anteriores (si solo quieres borrarlo y recrearlo vacío, no tienes que borrar commit y reañadir commit, basta con editar el fichero añadiendo una línea vacía sin quitar nada y al hacer el add y el commit, verá que hay un repositorio no creado y lo recreará).

Se ha usado la siguiente script (<tt>importa-todo.sh</tt>, teniendo en <tt>Repositorio</tt> los snapshots del programa y en ControlId el directorio montado y vacio donde se va a poner la versión final):
<table border=1><tr><td><code>
#!/bin/bash
export GIT_AUTHOR_IDENT="Guillermo Gonzalez <ggonzalez@sicosoft.es>"
export GIT_COMMITTER_IDENT="Guillermo Gonzalez <ggonzalez@sicosoft.es>"
cd /home/arcom
rm -rf /home/arcom/ControlId/.git
( cd /home/arcom/ControlId/ && mkdir t278 && mv * t278 2>/dev/null ; rm -rf t278 )
cd /home/arcom/ControlId
git init
mkdir -p /home/arcom/t
cd /home/arcom/Repositorio
for i in `ls -1 | sort` ; do
cd /home/arcom/t
rm -rf ControlId changelog
tar -xvzf /home/arcom/Repositorio/$i
if [ -d ControlId.2004-12-29 ] ; then
	mv ControlId.2004-12-29 ControlId
fi
if [ ! -d ControlId ] ; then
	continue
fi
rm -f changelog
fecha="`echo $i | cut -d '.' -f 2`T00:00:00"
export GIT_AUTHOR_DATE=$fecha
export GIT_COMMITTER_DATE=$fecha
echo "`echo $i | cut -d '.' -f 2`: version `echo $i | sed 's/ControlId.//g;s/.tar.gz//g'`" > changelog
echo "" >> changelog
if [ -e ControlId/ChangeLog ] ; then
	cat ControlId/ChangeLog | sed "0,/---/d" | sed "/---/,\$d" | sed '$d' >> changelog
fi
cd ControlId
git --git-dir=/home/arcom/ControlId/.git add -A
git --git-dir=/home/arcom/ControlId/.git commit -F ../changelog
if [ "`echo -n $i | tr -dc . | wc -c`" != 3 ] ; then
	git --git-dir=/home/arcom/ControlId/.git tag -m "Tag for `echo $i | sed 's/ControlId.//g;s/.tar.gz//g'`" `echo $i | cut -d '.' -f 3- | sed "s/.tar.gz//g"`
fi
done
cd /home/arcom/t/ControlId
tar -cf - . | ( cd /home/arcom/ControlId &amp; tar -xf - )
cd /home/arcom/ControlId
git branch
git remote add controlid git@chibiko:controlid.git
git push controlid master
</code></td></tr></table>

Para hacer un nuevo "clon" del repositorio en otro equipo, basta con hacer un:
= git clone git@chibiko:controlid.git

FALTA: Actualizar los ficheros que usa el gitweb para que aparezcan en la web de chibiko los fuentes.
_
<tt>Friday, 20 July 2012, 4:21:01 pm</tt>
Importar snapshots de código al Git Se hace según *este post>http://stackoverflow.com/questions/3147097/how-to-prepend-the-past-to-a-git-repository*. Básicamente es unsar *esta script>https://github.com/git/git/blob/master/contrib/fast-import/import-tars.perl*.
Otras maneras: 
- *Importar directorio a directorio>http://programmers.stackexchange.com/questions/33868/script-tool-to-import-series-of-snapshots-each-being-a-new-edition-into-git-p*
- *Otra manera de importar directorio a directorio (del propio Linus)>http://kerneltrap.org/mailarchive/git/2007/7/30/253342/thread*.
- *Poner una fecha determinada al hacer un commit>http://stackoverflow.com/questions/3895453/how-do-i-make-a-git-commit-in-the-past*. *Man page de git-commit con fecha>http://www.kernel.org/pub/software/scm/git/docs/git-commit.html#_date_formats*.

_
! Descripción del proyecto

Habilitar Git y el hacer varios repositorios en <tt>chibiko</tt> de manera que sea el servidor del sistema de control de versiones distribuido de SICO.

Para instalarlo se ha seguido el *tutorial de instalación de git junto con gitolite>http://blogs.gentoo.org/tampakrap/gitolite-installation-with-gitweb-and-anongit-in-gentoo-and-debian/* (*y otro>http://www.mmncs.com/2011/07/how-to-install-and-setup-a-git-repository-server-using-gitolite-on-linux-ubuntu-11-04-server-and-client/*).

Además, para que acepte hacer "clones" y demás como usuario git, he seguido este *post>http://serverfault.com/questions/102697/unix-user-alias* para hacer un user_alies desde gitolite a git:

= # useradd -o -u 117 git
y después he editado <tt>/etc/passwd</tt> para que <tt>git</tt> tenga el mismo grupo, homedirectory y shell que <tt>gitolite</tt>.
Para que el gitweb vea la lista de proyectos del gitolite, he hecho:
= # chmod 640 /var/lib/gitolite/projects.list

NOTA: Por ahora sólo soporta el "dsa_id" del usuario <tt>dario@phonedevel</tt>. Habrá que añadir más de alguna manera... (ver <a href="#20131117161743">Thursday, 17 January 2013, 4:17:43 pm</a>).

Y por último, leer el *TUTORIAL DE GIT>http://www.mmncs.com/2011/06/a-list-of-useful-common-git-commands-explained-distributed-version-control-developer/* aunque más bien es un "cheat-sheet" que otra cosa.

También es interesante haber leído algunas *guidelines for commit messages>https://github.com/hpcc-systems/HPCC-Platform/wiki/Git-commit-message-guidelines*.

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: