Cómo deshacerse de dependencias falsas en gerrit

Parece que al usar gerrit, por defecto todos los cambios dependen de la anterior. No ramifico para nuevos cambios, simplemente trabajo fuera de la rama maestra y luego envío los cambios comprometidos a un origen/maestro remoto. Se crea una dependencia cada vez, incluso si las dos confirmaciones no tienen nada que ver entre sí.Cómo deshacerse de dependencias falsas en gerrit

He tenido algunos problemas que me hacen pensar que no estoy usando git correctamente en combinación con gerrit.

¿Qué sucede de forma diferente en mi flujo de trabajo de git/gerrit para que cada compromiso no dependa de la confirmación anterior? También he intentado crear una nueva rama para el cambio:

> git pull origin master 
> git checkout -b new_branch 
> #make a change 
> git add -A 
> git commit #with gerrit's commit hook in .git/hooks 
> git push origin <sha1>:refs/for/master

Esto funciona, pero Gerrit todavía divulga una dependencia de la partida previamente comprometidos.

Fuente

2012-05-01 Shellum

Ni siquiera estoy seguro de lo que estás preguntando. ¿A qué te refieres con "una dependencia"? – ebneter

Gerrit muestra los problemas que dependen de/a la dependencia de. Por ejemplo, verifico en el número 1 a Gerrit, y luego controlo un # 2 completamente diferente que ni siquiera toca el mismo archivo. Gerrit informa que el # 2 depende del # 1. Esto parece incorrecto – Shellum

usando un git rebase -i y eliminando las dependencias usted mismo también puede ser una manera de deshacerse de las dependencias. – cafebabe1991

Esto es lo que significa Gerrit por dependencias: una confirmación que se encuentra encima de otra confirmación. Si ambos están en revisión, el más nuevo depende del anterior.

Si no desea que dependan el uno del otro, no cree las confirmaciones una encima de la otra. Cree una confirmación, luego cree una nueva rama basada en el maestro para su próxima confirmación

(git checkout origin/master -b NEW_BRANCH_NAME).

Cuando presione el segundo compromiso para su revisión, su padre ya estará publicado y no dependerá de nada.

Fuente

2012-05-01 21:36:11 Brad

He visto mencionar la ramificación para cada cambio de código ... pero como en mi pregunta editada, esto todavía parece producir los mismos resultados. ¿Alguna idea más? – Shellum

El comando que está utilizando para crear una bifurcación (git checkout -b new_branch) hace que la nueva bifurcación se encuentre encima de la confirmación actual. Desea volver a restablecer lo que el servidor ve como la confirmación actual, así que especifíquelo en el comando de finalización de compra.git checkout * origin/master * -b new_branch. – Brad

@Brad Tu comentario tiene sentido. Solo quería señalar que la documentación para git-checkout tiene el punto de partida como el último parámetro: git checkout [-q] [-f] [-m] [[-b | -B | --orphan] ] [] Así que su ejemplo podría ser: git checkout -b new_branch _origin/master_ – Plazgoth

Me han enseñado a solucionar esto haciendo git reset --hard HEAD~1 después de cada git push.

Fuente

2012-06-07 09:04:02 Mitch

¿Te gustaría comentar por qué piensas que esto está mal, quizás para evitar perpetuar la desinformación y para informarme mejor? – Mitch

El problema con este enfoque es que se deshace de la confirmación completamente después de presionar. Supongamos que tiene revisiones iterativas en gerrit, es posible que desee cambiar la confirmación anterior en función de los comentarios. Este enfoque requeriría que eligiera nuevamente el cambio de gerrit para poder trabajar en él. Encuentro esto difícil en los casos en que me extiendo para hacer una gran corrección y la instalación se ejecuta en ese código. Si deseo aplicar una corrección independiente menor en la misma línea de código, no quiero perder la confirmación mayor para esta corrección menor ya que eso podría atraer más cambios basados en las revisiones. –

No hay problema en absoluto. Todas las confirmaciones que se han enviado se almacenan en el servidor y localmente. Trabajas en una, la presionas, luego trabajas en otra. Cuando recibes retroalimentación sobre una y quieres modificarla nuevamente, simplemente la verificas para trabajar en ella. Ponerle un nombre de rama es una conveniencia, nada más. – clacke

Como variante a git reset --hard HEAD~1 utilizo este lugar:

git reset --hard origin/master

Suponiendo, estoy trabajando en master para un cambio rápido.

De lo contrario, trabajar en una rama de tema es muy preferido.

Hay muchas secuencias de comandos de Git para ayudar a manejar ramas puntuales:

git-flow
git extras
git create-branch

estoy seguro de que hay otros.

Fuente

2013-03-13 14:25:57

Creo que "git reset - hard origin/master" es mejor ... porque el comando de arriba dio error y funcionó después de dar espacio en el disco duro –

Cómo deshacerse de dependencias falsas en gerrit

Respuesta

Cuestiones relacionadas