Lines Matching full:se

26 Se non siete pratici di ``git``, allora è bene che lo impariate;
36 Se non avete un repositorio coi sorgenti del kernel più recenti, allora usate
62 Anche se il problema è stato scoperto durante la revisione del codice,
72 Quantificare le ottimizzazioni e i compromessi. Se affermate di aver
87 I manutentori vi saranno grati se scrivete la descrizione della patch in un
91 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
106 xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo
109 Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno
111 riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
132 Se volete far riferimento a uno specifico commit, non usate solo
145 caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il
148 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
176 Per esempio, se i vostri cambiamenti per un singolo driver includono
178 allora separateli in due o più patch. Se i vostri cambiamenti includono
182 D'altro canto, se fate una singola modifica su più file, raggruppate tutte
190 Se al fine di ottenere un cambiamento completo una patch dipende da un'altra,
198 della vostra serie in un punto qualsiasi; non vi saranno grati se nel mezzo
201 Se non potete condensare la vostra serie di patch in una più piccola, allora
225 giudizio umano. Se il vostro codice è migliore nonostante una violazione
244 vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
269 Se avete una patch che corregge un baco di sicurezza che potrebbe essere
286 Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
307 Se decidete di non usare ``git send-email``:
311 Se decidete di copiare ed incollare la patch nel corpo dell'e-mail, state
321 Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
363 in una settimana o poco più; se questo non dovesse accadere, assicuratevi di
399 come patch open-source. Le regole sono abbastanza semplici: se potete
433 contributi anonimi). Questo verrà fatto automaticamente se usate
435 includere "Signed-off-by", se usate ``git revert -s`` questo verrà
456 Se una persona non è direttamente coinvolta con la preparazione o gestione
476 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
525 Rammentate che se il baco è stato riportato in privato, dovrete chiedere il
557 non garantisco (se non specificato altrimenti) che questa
573 aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
580 non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
603 Notate che se state usando un repositorio ``git`` per salvare le vostre patch
615 da una riga vuota (necessaria soltanto se la persona che invia la
668 Se ci sono quattro patch nella serie, queste dovrebbero essere
687 l'autore della patch. Se la riga ``from`` è mancante, allora per determinare
701 Se la patch corregge un errore di compilazione, non sarà necessario
712 Un ``diffstat`` è particolarmente utile per le patch grandi. Se
727 in git. Queste sono informazioni utili solo ai revisori. Se venissero
779 giungla di riferimenti all'interno dei programmi di posta. Se un collegamento