Feda /dev/

Saphyel

#27778 uso Github y ningun problema?
Reconozco que algunos de mi equipo si que tienen problemas para entender que los comentarios son en commits no en el resultado final, pero el ya se va, por lo que ya no es mi problema.

eondev

Hablando de esto, a alguien le ha pasado que le salte 404 un repo de gitlab? Un compañero le salta en su ordenador que el repositorio no existe, está invitado y hace un mes podía entrar, tiene los permisos sin embargo no puede acceder al repo por la web ni clonar. :psyduck:

Traber

#27778 Code reviqué

1 respuesta
zoeshadow

#27780 Muchas veces los cambios que quiero ""apilar"" no están en commits consecutivos, muchas veces pasa que cuando estas probando lo que has desarrollado salen cosas de commits anteriores.
Un ejemplo sería, este "hunk" del fichero 1 y este otro "hunk" del fichero 2, tienen la finalidad X, pero otros cambios en esos ficheros los podría meter en otro "grupo de cambios".
Esto permitiría a los reviewers entender mucho mejor los cambios, muchas veces mostrar los cambios agrupados por fichero o por commit no tiene sentido.
Ahora mismo la única solución que hay para esto es una vez termines todo tu trabajo, deshacer estos cambios y rehacer los commits con esta finalidad, pero no me gusta modificar de esa manera tan sintética los cambios.

Y sí, añadir contexto me refería a añadir comentarios a ""grupos de cambios"", incluso permitiría añadir screenshots (trabajo en apps móviles que son muy visuales)

2 respuestas
Ranthas

#27783 No review, only approve!!

yasurio

Yo soy mas de overwrite que de commit

desu

#27784 Si el equipo hace bien los rebases y demás no solucionas la gran parte de este problema?

2 respuestas
eZpit

#27784 Sé que es un poco utópico (ya que a nosotros nos acaba pasando igual) pero la idea seria que cada PR contenga un único cambio conceptual.
Para documentar y dar contexto, que problema hay en hacerlo en la descripción y/o comentarios del PR?

2 respuestas
Saphyel

#27788 hay gente que le gusta perder el tiempo con los git bisect

Merkury

#27787 es esta la señal para volver al tema de que los rebases son el demoño? Hace casi un año que no nos tiramos de los pelos sobre esto.

2 respuestas
eZpit

#27790 En papel los rebases pintan bien.

Traber

https://status.github.com/

01:09 hora de verano de Europa centralWe are investigating reports of elevated error rates.
01:13 hora de verano de Europa centralWe are investigating reports of service unavailability.
[...]
08:18 hora de verano de Europa centralWe continue work to repair a data storage system for GitHub.com. You may see inconsistent results during this process.
1 respuesta
Markitos_182

Seguro que pasaron el almacenamiento a NTFS y claro.

zoeshadow

#27787 Los problemas se pueden dar incluso sin haber habido cambios en Master entre medías, por lo que hacer rebase vs merge no cambiaría nada.

#27788 totalmente de acuerdo en que si las PRs solo tuvieran un único cambio esto no haría falta, para mi eso tiene sentido en codebases que están maduras y en las que participa mucha gente, pero codebases pequeñas que tienen bastante legacy, poniéndote estricto con eso solo consigues que la gente toque lo mínimo para añadir X y siga metiendo legacy a saco.

#27790 Yo antes era fan de rebases y squash, pero desde que trabajamos unos cuantos en mi proyecto prefiero no alterar el historial de ninguna manera, no da más que problemas....

eZpit

#27792 lol habrán instalado en güindous

MisKo

Me hago mayor, un día que salgo del finde y el siguiente estoy reventadísimo en el sofa :\

Asi no hay quien arregle los deploys del viernes

Lecherito

Lol fan de los merges en vez de los rebase ya lo que me faltaba por leer aquí kek

1 respuesta
flopi01

#27778 Yo he probado un plugin de vs code que te agiliza a la hora de hacer core review en github y la verdad que parece muy sencillo para probar codigo y comentar lineas.

https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

1 respuesta
Merkury

#27797 los rebases solo les gustan a la gente rarita.

B

Menudas odiseas os pasan para equipos de 7, 12 personas.... OS ORGANIZAIS COMO EL OJETE DE MORDOR xD

1 respuesta
GlatoR

Eso es porque el jefe de proyecto es tonto

Troyer

#27800 un equipo de 7 devs es gigante, 12 ya una locura, máximo 4.

1 respuesta
eXtreM3

Amigos del viento, estoy con fiebre y la cabeza no me da. Si tengo este string

lkbja owjrio djl kcvlkmxcl vkxcl jcvxkl numero: 3 (bljasuefow) laewr cvlxck vxcl

Cómo obtengo ese 3 en PHP? Sé que siempre tiene sólo un carácter.

2 respuestas
HeXaN

#27803 Con una regex.

1 respuesta
Amazon

#27803 [0-9]{1}

1 respuesta
eXtreM3

#27804 #27805

if(($aux_pos = strpos($aux_string, 'numero')) === true){
    $aux_string = substr($aux_string, $aux_pos + 8, 1);
}

bss.

No sabía que strpos devolvía un int, pensaba que siempre era bool.

3 respuestas
B

#27802 Cuando trabaja en una "grande" el equipo eran 8 personas + 1 analista ... repartidos en mesas abiertas de 4 personas.

Amazon

#27806 strposition

Traber

#27806

function retrieveNumberFromLine($aux_string){
	$aux_str_data = explode("numero: ", $aux_string);
	if(sizeof($aux_str_data) === 2){
		$aux_num_data = explode(" ", $aux_str_data[1], 2);
		if(sizeof($aux_num_data) === 2){
			$number = $aux_num_data[0];

			if(is_numeric($number)){
				return intval($number);
			}
		}
	}
	
	return FALSE;
}
1 respuesta
eXtreM3

#27809 te ha faltado incrustarlo en una vista y devolver el echo en una tabla.

1
Tema cerrado

Usuarios habituales

  • desu
  • Fyn4r
  • HeXaN
  • Merkury
  • eXtreM3
  • MisKo
  • Troyer