Elrond

robitex” post=81237Bellissimo intervento Elrond.
Grazie mille.
Certamente molto utile rendere la HISTORY automatica dai commenti ai commit.
Si ho visto il commento, certamente, ho già fatto la correzione ed aspetto qualcosa di più per fare il commit.
Sono sempre restio a fare commit “leggeri”…
R.

Sì, ho notato che non ti piace fare “piccoli” commit ma ne fai sempre molto corposi (scelta legittimissima, ovviamente, io invece spesso faccio molti micro-commit più che altro perché sono fanatico della “sicurezza” e non voglio mai correre il rischio di perdere anche il minimo lavoro fatto, ma si tratta solo di una mia fissazione 😆 ), con questo tuo modo di procedere potresti trovarti molto bene nel realizzare la cronologia come ho indicato sopra, risparmieresti il doppio lavoro di scriverla due volte, nei messaggi dei commit e nell’apposito file HISTORY.

Pagina 28, nota 2:

robitexNei moderni sistemi Unix il programma sh non è altro che un collegamento al
programma bash, la Bourne Again Shell divenuta lo standard tra le shell disponibili per
i sistemi aperti ed anche per quelli Mac.

Non è esattamente vero: sh è un link simbolico a una shell che rispetti lo standard POSIX che non necessariamente è la bash, anzi per Debian e derivata (compresa Ubuntu, quindi stiamo parlando di una grossa fetta dei sistemi operativi GNU/Linux) /bin/sh punta a /bin/dash (Debian Almquist Shell), che è ben diversa dalla bash (è molto meno potente della bash). Uno shell script che voglia essere portabile attraverso i diversi sistemi operativi deve o avere esplicitamente /bin/bash nella shebang oppure, se usa /bin/sh come interprete, seguire pedissequamente lo standard POSIX ed evitare come la peste funzioni proprie solo di alcune shell. A questo proposito, un utente Debian sul suo blog pubblica ogni mercoledì a bashism a week, cioè una funzione esclusiva della bash che deve essere evitata nello scrivere script portabili

Sam Qasbah” post=80972cosa c’entra l’albero locale? Forse c’entra, ma io non lo so perchè non sono un esperto di git (se lo fossi non avrei bisogno di leggere l’apposita guida)

L’albero locale è l’albero locale della distribuzione TeX Live, non ha niente a che vedere con Git 😉 Sul mio computer ho messo il file guidatematica.cls e i due loghi nella cartella [tt]~/texmf/tex/latex/guidatematica[/tt], in questo modo (dopo aver eseguito il comando [tt]texhash ~/texmf[/tt]) la classe è visibile a latex in qualunque cartella si trovi il sorgente da compilare

antonio.macrì” post=80949Ma andiamo al sodo: paragrafo 3.4.1.

Se si vogliono riportare allo stato dell’ultimo commit registrato solo determinati file che sono modified ma non ancora staged, adottando la terminologia vista all’inizio, senza toccare la restante working directory si può utilizzare il comando
`$ git commit — < file >`

Immagino si intenda [tt]git checkout[/tt].

Immagini bene, ho corretto. Grazie

antonio.macrì” post=80949Non mi risulta che [tt]–[/tt] sia necessario. Come al solito, è consigliato se si possono avere ambiguità, ma non mi pare sia obbligatorio. Ovviamente, dato che il file è stato cancellato, non è possibile usare TAB per completarne automaticamente il nome, ma non per questo non viene riconosciuto da git.

È vero, non è obbligatorio ed è anche scritto in quel paragrafo.

antonio.macrì” post=80949A seguire:

I file tolti dalla staging area possono poi anche essere ripristinati allo stato del commit precedente usando il comando git commit — illustrato qui sopra.

Come sopra: [tt]git checkout[/tt]?

Come sopra 🙂

antonio.macrì” post=80949Infine, opinione personale, io lascerei stare [tt]inotifywait[/tt] che va completamente contro il senso di un sistema come git, in cui ogni commit dovrebbe avere uno specifico obiettivo.

Su questo punto sono d’accordo, nelle future versioni della mia versione della guida potrei rimuovere questo paragrafo.

Ho contattato dianoia su gitorious per (ri)coinvolgerlo, spero risponda.

antonio.macrì” post=80949Chiedo agli autori: per caso avete intenzione di trasferire il repository su GitHub?

Più tardi mi occupo di spostare il mio branch su GitHub e do un’occhiata ai tuoi suggerimenti. Grazie!

robitex” post=80954Ho provato emacs. In questo casi non sono riuscito a fare un gran che per mia scarsa conoscenza.

Nel file di inizializzazione di Emacs (il nome dipende dal sistema operativo utilizzato) dovresti aggiungere
`(setq-default fill-column 80)
(add-hook 'latex-mode-hook 'turn-on-auto-fill)`
se usi la versione standard di Emacs, altrimenti
`(setq-default fill-column 80)
(add-hook 'LaTeX-mode-hook 'turn-on-auto-fill)`
se usi il pacchetto AUCTeX.

Dopo aver riavviato Emacs, ogni qual volta supererai l’ottantesimo carattere per riga di un documento LaTeX verrai automaticamente mandato a capo, puoi automaticamente riformattare il paragrafo in cui si trova il cursore con la scorciatoia da tastiera Alt + Q (gli ambienti matematici non sono toccati proprio per evitare problemi)

robitex” post=80916

@robitex: quale editor di testo utilizzi? TeXworks? È possibile in questo editor limitare automaticamente il numero di caratteri per riga a un certo numero fissato? Un conto è guardare il diff di una riga di 80 caratteri, un altro è per una riga di 800 😆 (è solo un consiglio, ma lavora come preferisci tu)

Tu cosa consigli?

Il mio consiglio sarebbe quello di limitare il numero di caratteri per riga (in genere circa 80), aiuta leggermente la leggibilità del codice per le finestre a tutto schermo, soprattutto su schemi con alta risoluzione, è pesante leggere righe di centinaia di caratteri (ricorda il famoso tormentone dei margini 😆 ), inoltre permette di individuare più facilmente le modifiche quando si fa uso dei diff (come con i vari sistemi di controllo delle revisioni): andare a ytovare una microscopica modifica (per esempio una virgola in più o in meno) su una riga di centinaia di caratteri diventa un’impresa simile alla ricerca dell’ago nel pagliaio, invece con una riga di pochi caratteri è molto più semplice.

Esempio: senza evidenziazione (nel terminale le differenze non sono evidenziate, ci sono solo colori diversi per le righe aggiunte ed eliminate), sfido chiunque a trovare rapidamente la modifica al file [tt]section/notefinali.tex[/tt] nel commit https://github.com/GuITeX/guidalineadicomando/commit/d265884480e00f59b23538280b2be5ed98ed5f11 (la riga è lunga oltre 400 caratteri)

Se però limitare il numero di caratteri per riga comporta una complicazione del proprio normale lavoro lo sconsigli. Emacs e Kile mandano automaticamente a capo una volta superato il limite, se ho capito bene TeXworks permette di riformattare il codice dopo che è stato scritto ma manda a capo automaticamente mentre si scrive, lo sviluppatore di Texmaker si è rifiutato di sviluppare questa funzione, non so quale sia la situazione per gli altri editor