Re: [gnome-es] Pregunta sobre funcionamiento del repo
- From: Francisco Vila <paconet org gmail com>
- To: daniel mustieles gmail com
- Cc: Grupo GNOME-es <gnome-es-list gnome org>
- Subject: Re: [gnome-es] Pregunta sobre funcionamiento del repo
- Date: Wed, 16 Feb 2011 17:29:17 +0100
El día 16 de febrero de 2011 17:15, Daniel Mustieles García
<daniel mustieles gmail com> escribió:
> Realmente lo que comentas sí es un merge, ya que (hasta donde yo sé, quizá
> me meto en un campo que no domino demasiado), Git no está orientado sólo a
> traducciones, por lo que si yo subo una cadena sin traducir a un repositorio
> donde esa cadena sí estaba traducida, el merge toma como buena la cadena que
> yo subo, pero de la misma manera que si en vez de borrar la traducción, la
> hubiese modificado.
Efectivamente. En tu árbol local cambias unas líneas de un archivo,
el commit consiste en cambiar esas líneas. Si las líneas estaban
traducidas y el archivo nuevo no las tiene traducidas, esas líneas
constan como una "destraducción."
> De este modo, si yo subo un .pot al repositorio pero lo llamo es.po, me
> cargo la traducción entera que hubiese, pero porque Git no "sabe" de
> traducciones. Por otro lado, comentas que " Depende del tipo de commit que
> haga el encargado de subir el archivo a Git". Hasta donde yo sé, sólo hay un
> tipo de commit,
Sí, sólo hay un tipo de commit. Con "depende del tipo de commit",
fatalmente expresado, quiero decir "depende de lo que hagas con el
archivo antes de acometerlo". Si lo recibes y lo subes como lo has
recibido, eso es una sustitución de todas las líneas, no hay mezcla
que valga.
> Respecto a lo de las ramas, no estoy muy seguro de que las ramas se mezclen
> automáticamente.
No se mezclan automáticamente. Se mezclan manualmente, pero la mezcla
de los archivos es automática aunque en distintas ramas se hayan
modificado los mismos archivos. El archivo resultante contiene las
modificaciones en cada línea que tuviera cada rama. Sólo hay
conflicto cuando dos ramas modifican las mismas líneas de los mismos
archivos. En ese caso es necesario resolver el conflicto de forma
manual.
> Al menos en mi caso, si tengo que subir algo a gimp-2.6,
> antes que hacer un checkout de esa rama, subir el archivo, y luego volver a
> la rama gimp-master, es decir, los cambios que subo a la rama master no se
> propagan a las ramas inferiores.
Correcto, si haces eso no se propagan, pero es posible (y fácil)
propagarlas si estás en una de ellas y haces git merge master.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]