Lines Matching full:come
18 dettagli su come funziona il processo di sviluppo del kernel leggete
82 Una volta che il problema è chiaro, descrivete come lo risolvete andando
85 comporti come descritto.
89 ``git``, come un "commit log". Leggete :ref:`it_the_canonical_patch_format`.
106 xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo
156 i risultati dei comandi ``git log`` o ``git show`` come nell'esempio
224 di stile dovrebbe essere visto come una guida, non come un sostituto al
282 nella vostra patch, nell'area dedicata alle firme (notate, NON come destinatario
303 come testo. Il modo più facile, e quello raccomandato, è con ``git
317 MIME come puro testo, e questo rende impossibile commentare il vostro codice.
322 potrebbe chiedervi di rinviarle come allegato MIME.
332 invieranno dei commenti su come migliorare la vostra patch. Dovete
399 come patch open-source. Le regole sono abbastanza semplici: se potete
464 Acked-by: non è formale come Signed-off-by:. Questo indica che la persona ha
653 come ``gitk`` o ``git log --oneline``.
662 Le etichette non verranno considerate come parte della frase riassuntiva, ma
663 indicano come la patch dovrebbe essere trattata. Fra le etichette più comuni
686 La riga ``from`` indica chi verrà accreditato nel changelog permanente come
704 venga trovata. Come nella ``summary phrase``, è importante essere sia
793 Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"
814 Andi Kleen, "Su come sottomettere patch del kernel"
815 Alcune strategie su come sottomettere modifiche toste o controverse.