È buona norma dividere un commit in due, dove uno è il contenuto, l'altro è il cambio di stile (indent)?

Penso che lo stia prendendo troppo lontano. Mettere cambiamenti funzionali e cambiamenti stilistici in diversi commit è una buona pratica in quanto mantiene i commit focalizzati e comprensibili. Tuttavia, indentazione è un aspetto quasi funzionale del codice - indica quale livello di nidificazione ci troviamo in ogni blocco, il che dice molto su come il codice verrà eseguito. Quindi non sarei d'accordo sul fatto che abbiamo due modifiche "annida questo blocco" e "indentiamo questo blocco", piuttosto hai una modifica "annida questo blocco" che con le convenzioni della formattazione del codice richiede "rientro questo blocco".

Il blocco che fa parte del cambiamento è nella mia mente una cosa buona in quanto rende più chiaro ciò che è cambiato. Se avessi due commit separati come proponesti, uno potrebbe facilmente guardare il primo commit e dire "okay, hanno aggiunto un'istruzione if , ma che diamine è il corpo di quella dichiarazione?" e poi "okay, hanno rientrato in questo blocco di codice, perché mai l'hanno fatto?" Mentre con un commit non c'è confusione.

Penso che questo sia anche un caso in cui potresti dover usare meglio i tuoi strumenti. Dove lavoro, il nostro software di revisione cr rende chiaro quando una parte di una diff è causata da cambiamenti negli spazi bianchi, e si può usare git per fare anche questa distinzione (ad es. Con git diff -w ).

Ovviamente è una buona idea. Il commit di un cambio di semantica è abbastanza diverso dal commit di un cambio di indentazione.

Tuttavia, perché stai modificando il rientro? La regola generale della vecchia scuola era che il manutentore di un corpo di codice dovesse convivere con lo schema di indentazione dello sviluppatore originale. Ci sono delle eccezioni alle eccezioni a questa regola, ma l'intento della regola è di mantenere (1) evitare di modificare le guerre, e (2) evitare i commit che hanno un significato semantico zero.

Supponiamo di trovare un file nel codice di configurazione gestito che viola palesemente gli standard di codifica della tua organizzazione. È molto probabile che non sia l'unico file. Dovresti creare una nuova richiesta di modifica (o qualsiasi altra cosa venga chiamata nella tua organizzazione) per correggere tutti di tali problemi. Il commit potrebbe colpire qualsiasi cosa, da un file a migliaia, ma se la riformattazione viene eseguita da uno strumento ben testato, avrà un impatto semantico zero.

La nuova regola della scuola è che i commit / push saranno (a) automaticamente riformattati su uno stile comune concordato su commit / push, o (b) respinti se il codice in questione non si conformerà con quello stile. Ad ogni modo, non avrai problemi con il codice che si discosta dallo stile con cui tutti hanno accettato di rispettare.

Penso che sia meglio dividere il commit in due. Mantiene chiaro l'intento dei commit.

Cerco di farlo ma so anche che non lo attengo religiosamente. Se noto i problemi di formattazione prima di iniziare a apportare modifiche al contenuto, cerco di risolvere prima i problemi di formattazione e di verificare le modifiche prima di intervenire sulle modifiche del contenuto. Se noto i problemi di formattazione dopo aver apportato modifiche al contenuto, ignoro i problemi di formattazione o invii entrambe le modifiche in un unico commit.