Lines Matching full:come
67 Come regola generale, pensarci un po' di più prima di inviare il codice
79 Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
80 così come lo si trova nei sorgenti git di Linus. Quando vi basate sul ramo
92 Solo le modifiche più semplici dovrebbero essere preparate come una singola
93 patch; tutto il resto dovrebbe essere preparato come una serie logica di
95 passano molto tempo nel capire come farlo in modo che piaccia alla comunità.
100 come quella che trovate nel vostro sistema di controllo di versione.
106 - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
126 difficile così come quella di chi s'impegna nel nobile lavoro di
136 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
139 regressioni, "bisect" indicherà quest'ultima patch come causa del
201 modifiche e come gli altri dovrebbero agire per applicarle. In generale,
217 Le etichette sopra menzionante sono usate per descrivere come i vari
284 ragionamenti su come debba essere una patch per il kernel. Se seguire
287 Le patch dovrebbero essere sempre inviate come testo puro. Per favore non
288 inviatele come allegati; questo rende molto più difficile, per i revisori,
298 - I manutentori dei sottosistemi affetti della modifica. Come descritto
340 introduttiva come parte zero. Tuttavia questa convenzione non è universalmente
346 dovrebbero essere inviate come risposta alla prima, cosicché vengano viste
347 come un unico *thread*. Strumenti come git e quilt hanno comandi per inviare