Lines Matching refs:por
93 Resuelva solo un problema por parche. Si su descripción comienza a ser muy
107 Describa sus cambios en la forma imperativa, por ejemplo, "hacer que xyzzy
124 objetos, por lo que las colisiones con identificaciones más cortas son una
131 apunten a estos. En caso de que su parche corrija un error, por poner un
153 Si su parche corrige un error en un commit específico, por ejemplo
194 ser verificado por los revisores fácilmente. Cada parche debe ser
195 justificable por sus propios méritos.
270 este momento, muy pocos parches pasan por Linus directamente, por lo que
307 Por este motivo, todos los parches deben enviarse por correo electrónico
321 archivo adjunto como texto sin formato, por lo que es imposible comentar
393 otras discusiones por correo electrónico.
404 en parches que se envían por correo electrónico.
416 (a) La contribución fue creada en su totalidad o en parte por mí y
421 soy consciente, está cubierto por una licencia de código
424 totalidad o en parte por mí, bajo la misma licencia de código
428 (c) La contribución me fue proporcionada directamente por alguna
444 anónimas). Esto se hará por usted automáticamente si usa ``git commit -s``.
446 ``git revert -s`` hace eso por usted.
449 serán ignoradas por ahora, pero puede hacer esto para marcar procedimientos
460 Cuándo usar Acked-by:, Cc: y Co-developed-by por:
478 de un acker en un Acked-by: (pero tenga en cuenta que por lo general es
490 Esta es la única etiqueta que se puede agregar sin una acción explícita por
495 Co-developed-by: establece que el parche fue co-creado por múltiples
497 autor atribuido por la etiqueta From:) cuando varias personas trabajan en
510 Ejemplo de un parche enviado por el From: autor::
520 Ejemplo de un parche enviado por un Co-developed-by: autor::
535 La etiqueta Reported-by (Reportado-por) otorga crédito a las personas que
538 etiqueta Reported-by. La etiqueta está destinada a errores; por favor no la
542 entorno) por la persona nombrada. Esta etiqueta informa a los maintainers
579 las otorgan revisores conocidos por entender del tema y realizar
584 correo por el tester o revisor, deben ser incluidas por el autor de los
587 etiquetas ya no sean aplicables y, por lo tanto, deben eliminarse. Por lo
592 Una etiqueta Suggested-by: indica que la idea del parche es sugerida por la
593 persona nombrada y asegura el crédito a la persona por la idea. Tenga en
604 método preferido para indicar un error corregido por el parche. Revise
649 electrónicos alfabéticamente por línea de asunto - prácticamente cualquier
664 convierte en un identificador global único para ese parche. Se propaga por
669 podrá ver rápidamente cuando, dos o tres meses después, estén pasando por
674 debe describir tanto lo que cambia el parche como por qué el parche podría
678 La ``frase de resumen`` puede estar precedida por etiquetas encerradas en
708 La explicación estará incluida en el commit del changelog permanente, por
717 razonamiento de **por qué** se creó el parche.
731 líneas insertadas y eliminadas por archivo. Un ``diffstat`` es
737 indentación). (``git`` genera diffstats apropiados por defecto).
796 (por ejemplo, al usar ``git send-email``) para asociar el parche con una
797 discusión anterior relevante, por ejemplo para vincular una corrección de
803 útil, puede usar el redirector https://lore.kernel.org/ (por ejemplo, en
837 correctamente ``git am`` sin preocuparse por los conflictos::
863 "The perfect patch" (tpp) por Andrew Morton.
866 "Linux kernel patch submission format" por Jeff Garzik.
869 "How to piss off a kernel subsystem maintainer" por Greg Kroah-Hartman.
890 "On submitting kernel patches" por Andi Kleen