antonio.macrì

Chiedo agli autori: per caso avete intenzione di trasferire il repository su GitHub?

Ho dato una lettura alla guida, alcuni paragrafi sono particolarmente scorrevoli, anche piacevoli da leggere. 😉 Comunque ho notato alcuni refusi e un paio di imprecisioni. Per il momento li segno qui, anche per discuterne (se volete potete integrarli voi, se li ritenete validi).

Innanzitutto, parlando di GUI io farei almeno una menzione a gitk o gitg.

Ma 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].

Poco dopo (infatti):

Il comando git checkout — può anche essere usato per ripristinare file accidentalmente cancellati prima effettuare un nuovo commit. In questo caso l’uso del doppio trattino è necessario dal momento che il file cancellato non si trova nella working directory e Git non capirebbe che è con certezza un elenco di file cancellati.

Non 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.

A 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]?

Paragrafo 3.4.2:

L’opzione –amend del comando git commit permette di modificare l’ultimo commit, ma a patto che non sia già stato inviato a un server remoto con git push. Questa apparente limitazione è dovuta al fatto che quando il server remoto riceve la nuova versione del repository non si aspetta che la cronologia dei commit che già conosce venga modificata e questa è una misura di sicurezza voluta dagli sviluppatori di Git che assicura che un repository non possa essere alterato da malintenzionati.

Sembra naturale pensare a una misura di sicurezza, ma in realtà non è così, o meglio: non in questo senso. Si può benissimo inviare al server remoto un commit modificato: basta usare [tt]git push -f[/tt]. Il motivo per cui va usato con attenzione è che altera la cronologia dei commit nel server remoto e può mandare in subbuglio i repositori degli altri sviluppatori (non mi è mai capitato ma leggendo in giro non sembra piacevole ;)). Se vogliamo trovare un motivo “di sicurezza”, è per costringere a fare il merge in locale, evitando che vada perso del lavoro. Per esempio se A e B partono dallo stesso commit, fanno ciascuno un commit nella propria copia di lavoro e poi A fa il push, se anche B potesse fare semplicemente il suo push, andrebbe eseguito un merge automatico in remoto …che git non prevede! 😉 Di conseguenza o si fa il merge locale o si perde il lavoro di A!

Un’altra cosa. Quando viene descritto [tt]git revert[/tt], dato che si cita HEAD, può essere il punto giusto per parlare delle notazioni [tt]^[/tt] e [tt]~N[/tt], che evitano di dover ricopiare l’hash certe volte. Infine, 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.

Ciao,
Antonio

EmilLask” post=80877Potrei realizzare degli script anche con TexMaker?

Tra chi lo utilizza c’è qualcuno che potrebbe mostrarmi un esempio di script?
Ad esempio: seleziono una successione di righe e in ogni riga aggiungo \item all’inizio e \\ alla fine.

Grazie

Emil

Per TeXworks, ammesso che [tt]\item[/tt] all’inizio e [tt]\\[/tt] alla fine abbiano un senso 🙂 ecco:
`// TeXworksScript
// Title: Itemize
// Description: Aggiunge \item all'inizio e \\ alla fine di ogni riga
// Author: Nome Cognome
// Version: 1.0
// Date: 2012-12-29
// Script-Type: standalone
// Context: TeXDocument
// Shortcut: Ctrl+K, Ctrl+Z

var selection = TW.target.selection;
if (selection != “”) {
selection = selection.replace(/^/gm, “\\item “);
selection = selection.replace(/$/gm, “\\\\”);
TW.target.insertText(selection);
}
undefined;`
La prima porzione è un’intestazione con dei metadati. L'[tt]undefined[/tt] finale serve per evitare dei problemi con qualche vecchia versione di TeXworks.

Più info qui. Tutti gli script sono contenuti in una cartella che puoi raggiungere dal menu Script → Scripting TeXworks → Mostra cartella script.

Ovviamente in casi semplici come questo basta anche un cerca/sostituisci, ma in generale con gli script puoi fare roba piuttosto complessa. 😉

Ciao,
Antonio

PS: oops! è un forte off-topic, chiedo scusa… 😳

Elrond” post=80625Il workflow di un progetto collaborativo in genere è questo: un “capo” ha accesso al repository “ufficiale”, tutti gli altri utenti creano fork, fanno le modifiche sul proprio fork e poi chiedono il merge nel repository “ufficiale”. In pratica tutti glu utenti hanno accesso in scrittura solo al proprio repository. È (più o meno) necessario una gestione del genere perché se tutti avessero accesso in scrittura contemporanea a un unico repository si potrebbero facilmente creare conflitti di cui ognuno dovrebbe occuparsi, in questo modo se ne occupa solo il responsabile del repository principale 😛

Questo può avvenire per repository personali (ai quali in genere l’unico ad avere accesso in scrittura è chi li crea) o progetti molto grandi (per questioni di controllo e integrazione dei diversi commit). Ma se sul progetto lavora un team abbastanza compatto, allora tutti i membri hanno accesso allo stesso repository in scrittura. Peraltro, se il repo è open source (nel senso che tutti lo possono leggere), allora chiunque può contribuire in maniera meno diretta al progetto con qualche forma di pull request.

Alcuni che si avvicinano a Git temono i conflitti a priori, ma nei progetti comuni solitamente i conflitti sono abbastanza rari. Una delle caratteristiche più importanti di Git è che è un Distributed VCS: non esiste alcun server, soprattutto non esiste alcun meccanismo di lock (che ha invece SVN). Il lock può essere utile per file binari che vengono modificati spesso, per i quali non si può fare alcun merge. Ma quando si scrive un documento LaTeX si lavora quasi esclusivamente su file di testo (tex, sty, cls, dtx, eccetera: le eventuali immagini sono aggiunte all’inizio e quasi mai modificate) e allora spesso i conflitti possono essere risolti in maniera quasi automatica. Comunque sia, tocca proprio a ciascuno sviluppatore risolvere i conflitti, in locale.

Non va mai dimenticato quel “distributed”… 😉

Comunque l’accoppiata Git+LaTeX è fenomenale e son d’accordo che una guida tematica a Git sarebbe molto utile. Tempo permettendo, mi piacerebbe anche contribuire. 🙂

egreg9″ post=80519Non rispecchierà veramente la realtà, ma se il tuo scopo è di far riconoscere l’avviso ai metodi balordi di TeXStudio o Kile, è una via sicura. Perché “metodi balordi”? Perché disabituano l’utente a prestare attenzione al log; non hai idea di quanti esempi che producono errori, bellamente ignorati da chi chiede aiuto, si vedano in giro.

Punto di vista autorevole, ma personalmente non son d’accordo.

L’utente con un minimo di pratica sa che il log è importante, che può aiutare a risolvere dei problemi e sa che ogni tanto va letto comunque (per esempio io lo faccio prima della “consegna”). Ma non trovo affatto pratico leggerlo a ogni compilazione.

Per un principiante, trovo ingiustificabile chiedergli di scorrere ogni volta il log in cerca di avvisi (o errori), si perderebbe tra tutti quei file, quei numeri e quell’accozzaglia amorfa che ne vien fuori. Se gli errori sono ignorati da un utente inesperto, secondo me in gran parte ne è causa il meccanismo pressoché scriteriato che c’è dietro (TeX non aiuta affatto, ma spesso è colpa dei pacchetti; per fortuna mi pare che LaTeX3 stia cercando di render più razionale la gestione dei messaggi).

Perciò quei “metodi balordi” secondo me sono necessari. Non lo dico perché in quello di TeXworks c’è del mio, ma semmai è il contrario: l’ho scritto convinto dell’importanza di un decente riconoscimento dei messaggi.

Ogni tanto Lorenzo sottolinea qualche punto debole di LaTeX che spaventa i principianti e li allontana: ecco, secondo me questo è uno di quelli.

Se anche non si fosse potuto dare [tt]resume[/tt] in quel modo, valeva sempre la pena provare a racchiudere [tt]\setlist[/tt] in un gruppo: se il pacchetto è fatto a modo, i comandi come quello hanno effetto locale (e infatti, a parte casi particolari, così funzionano [tt]\captionsetup[/tt], [tt]\hypersetup[/tt], …).

`\documentclass[a4paper,11pt]{report}

\usepackage{enumitem}

\begin{document}
Ecco il primo elenco:
\begin{enumerate}
\item Uno
\item Due
\item Tre
\end{enumerate}

Ed ecco il secondo, che dovrebbe proseguire dal primo:
\begingroup
\setlist[enumerate]{resume}
\begin{enumerate}
\item Quattro
\item Cinque
\end{enumerate}
Anche:
\begin{enumerate}
\item Sei
\item Sette
\end{enumerate}
\endgroup

Ripartiamo da 1:
\begin{enumerate}
\item Nuovo Uno
\item Nuovo Due
\item Nuovo Tre
\end{enumerate}
\end{document}`

Benvenuto sul forum!

Hai letto la documentazione di toptesi (che puoi aprire dando [tt]texdoc toptesi[/tt] dal terminale)? Al momendo non ho una distribuzione per provare, ma i comandi presentati nel paragrafo 3.4 dovrebbero fare quello che cerchi.

Ciao,
Antonio

Complimenti per la nuova versione!
Per ora ho solo scorso velocemente le pagine, ho notato che nella prefazione compare la sezioncina “Sull’edizione 2012”: ma è 2012 o 2013? 🙂