[vim-doc-es] Re: [vim-doc-es] Re: merge y rebase en el repoç

  • From: Javier Rojas <jerojasro@xxxxxxxxxx>
  • To: vim-doc-es@xxxxxxxxxxxxx
  • Date: Mon, 10 Jan 2011 19:47:10 -0500

On Sun, Jan 09, 2011 at 09:06:21AM -0500, Pedro Alejandro López-Valencia wrote:
> 2011/1/8 Omar Campagne <ocampagne@xxxxxxxxx>
> 
> > Vaya, el histórico es de todo menos lineal :( Gracias por el toque de
> > atención. Te haré caso, aunque si me puedes resolver una duda...
> >
> > ¿Al hacer "git --pull rebase", no estoy fusionando cada revisión en uno
> > solo? Al hacer git log, ¿me saldría cada revisión de forma normal?

No. Lo que hace rebase, de manera predeterminada, es:

  * Quitar los commits (cambios) que hayas hecho desde la última vez que
    sincronizaste con el repo central (y que aún están sólo en tu copia
    privada).
  * Traer e incorporar a tu repo los cambios que llegaron al repo
    central desde la última vez que sincronizaste.
  * Re-aplicar tus cambios.

> > Lo siento, hasta ahora solo he usado rebase para fusionar commits, y
> > push. No lo entiendo bien, pero vamos, te haré un caso ciego.
> >
> El problema de rebase es que destruye la historia. Yo me ciño a la opinión
> de Torvalds. rebase se usa en copias privadas, quien lo use en un
> repositorio público debe ser exterminado, con prejuicio. :-)

rebase reconstruye historia, por lo que mencioné anteriormente: quita
los cambios privados, trae los públicos, y aplica los privados de nuevo.

El uso que sugiero sólo modifica historia privada; no estamos cambiando
la historia pública (de nuestro repo central). Ésa es la pelea de
Torvalds, que no se alteren commits una vez sean públicos. Es más, él
alienta el uso de rebase en situaciones como la nuestra, en la que
nosotros desarrolladores (leaf developers) seguimos un único upstream
(el repo de assembla), y nadie jala nunca cosas de nuestros repos
personales (que ni siquiera están en internet).

Como les mencioné en el correo inicial, podemos seguir trabajando con
git pull, y el cambio a git pull --rebase implicará simplemente que
nuestros commits aún privados (no enviados al repo principal) quedarán
en línea (literalmente) con lo que ya se encuentra en assembla.

Igual lo recomiendo.

Ver http://kerneltrap.org/Linux/Git_Management

Saludos,

-- 
Javier Rojas

GPG Key ID: 0x24E00D68

Other related posts: