LaTeX + git

Ciao,
ho provato git qualche tempo fa con il sito github. Lo trovo piuttosto interessante ed una guida come quella che stai preparando è molto utile.
Per aiutarti posso fare solo da tester, provando direttamente la guida e fornendoti un feedback, ma in questo momento sono piuttosto impegnato con il lavoro (per fortuna).

Vorrei che ogni tanto tu scrivessi agganciandoti a questo post le novità sulla tua guida per consentire agli utenti del forum interessati di essere aggiornati ed eventualmente cogliere un momento buono per contribuire.

Bye

ciao a tutti,
sto preparando un documento che descrive come usare git in accoppiata con latex.
Diciamo, quasi una guida 🙄
La licenza è CreativeCommons Attribution-NonCommercial-ShareAlike.

E da un po’ che aspettavo un messaggio del genere, ogni tanto tento di dire nel forum che si può utilizzare anche git per “sviluppare” documenti con LaTeX e tenere traccia delle modifiche (tipo nel topic per la nuova versione dell’Arte dei mitici Lorenzo&Tommaso) e privatamente lo faccio da un po’. Appena ho un attimo di tempo [1] do una occhiata a tutto quello che hai fatto sperando di esserti d’aiuto.

Ciao Alberto

[1] La rete dell’università non mi consente di scaricare le nulla da git e neanche di scaricare il file .pdf

Proprio qualche settimane fa ho iniziato a usare git per controllare lo sviluppo di un documento LaTeX (e volevo farlo in locale, quindi questo escludeva a priori l’uso di VCS centralizzati come subversion & Co.). Devo dire che mi sto trovando veramente bene (e ovviamente Emacs offre anche un buon supporto anche per git, almeno per le operazioni base come checkout, commit, log, diff; per le altre operazioni ci sono le immancabili estensioni) 😀

NOTA IMPORTANTE: segnalo che la guida iniziata da Pietro è stata pubblicata come guida tematica del GuIT ed è scaricabile da questo indirizzo. Il repository in cui viene gestito lo sviluppo si trova ora su GitHub: https://github.com/GuITeX/guidagit

Fra poco ho intenzione di creare un branch per apportare delle modifiche (appena mi registro su gitourius e capisco come funziona) 🙂

Edit: una buona risorsa per git da cui in alcuni casi si “potrebbe prendere ispirazione” (leggi “copiare” :D) è http://progit.org/book/, distribuita con la stessa licenza

@dianoia: ho qualche problema a capire come funziona gitourius (ma scrivere una guida all’uso sembrava molto brutto agli sviluppatori del sito? Su github c’è e da quel che ho visto mi è sembrata molto chiara). In particolare non ho capito come creare un branch… 😳
Dovrei prima clonare il repo da http://gitorious.org/git4latex/git4latex/clone (ho già fatto questa operazione ma da 15 minuti c’è scritto che verrà creato presto… sto iniziando a non amare molto il sito…) e poi? Clonarlo in locale? Grazie

Vabbè, alla fine ce l’ho fatta da solo (o almeno credo), il repo si trova all’indirizzo http://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex, il mio branch si chiama ovviamente elrond

anche io uso git con latex!
saro’ lieto di seguire/partecipare al tuo progetto (non appena ho un po’ di tempo).
sono gia’ su gitorious (c’e’ anche la mia tesi di dottorato li’) e presto clonero’ il tuo repository!

Descrivo brevemente le modifiche che ho fatto nel mio branch (http://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex/commits/elrond):
– ho modificato qualcosa nel preambolo (cambiate le impostazioni per l’aspetto di listings, quello sfondo colorato personalmente non mi piaceva molto, ma è questione di gusti 😉 );
– ho aggiunto un primo paragrafo sulle basi del funzionamento di Git (preso dal sito che ho citato prima, mi sembrava indispensabile aggiungerlo, se non avessi letto quello probabilmente non avrei capito nulla di Git);
– ho aggiunto qualche informazione nell’introduzione e anche, nella guida vera e propria, sull’uso di Git (ma davvero poca roba);
– ho fatto qualche altra correzione sparsa qua e là;
– inoltre ho scritto un piccolo Makefile per compilare il documento (ma anche per cancellare i file temporanei generati durante la compilazione, in modo da poter ricominciare la compilazione senza i file ausiliari già presenti), me ne creo sempre uno quando scrivo un documento sufficientemente elaborato.

Ho intenzione (come scritto nel file TODO) di scrivere un paragrafo su come creare dei branch e sulla loro gestione a livello base, ma davvero molto poco: come passare da un branch all’altro, come copiare un commit da un branch all’altro (cherry-pick, è una funzione che personalmente sto usando molto spesso), come effettuare il merge fra un branch e un altro (se tutto va bene è un solo comando, non c’è granché da dire).
Per ora il documento non è particolarmente lungo, ma se dovesse ampliarsi ho intenzione di cambiare la classe da article a book e magari suddividere il documento in più file tex contenente ciascuno un capitolo.

Per scaricare un archivio compresso contenente tutto il codice sorgente potete fare clic qui: http://gitorious.org/git4latex/elrondgits-git4latex/archive-tarball/elrond
Chi ha git può clonare il repository in locale con il comando
`git clone git://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex.git elrondgits-git4latex
cd elrondgits-git4latex # per entrare nella cartella
git checkout elrond # per aprire il branch`

Ho caricato il PDF qui (ma non sarà sempre aggiornato): http://elubuntu.altervista.org/LaTeX/git4latex.pdf

apprezzo le modifiche, specie quelle relative alla formattazione!
Noto in particolare che la procedura di ripristino è ora molto più chiara.

Grazie, ma grazie soprattutto a te per aver iniziato questa guida!

Che distro linux usi?

Ubuntu, ma ho notato che nella guida non è richiamato nessun comando specifico di un particolare sistema operativo Unix-like (echo, cd, mkdir, touch funzionano in qualsiasi sistema GNU, probabilmente andranno bene anche su Mac OS).

Cosa ne pensi di dare delle indicazioni utili per gli utenti windows?

Come te non ho mai usato né LaTeX né Git su Windows (anche perché uso Git davvero da poco) 😳

Potrebbe essere sufficiente, per iniziare, differenziare i comandi di git da quelli di bash.
O forse elaborare una section specifica (con screenshot?).

Su questo si può discutere

Credo che la procedura di checkout ad una versione precedente di un signolo file meriti una subsection a parte.

Questo non so farlo da git, per esempio (e mi interesserebbe, per ora ho usato Emacs per farmi vedere una versione precedente di un file)

A presto
Pietro

Ciao 🙂

Come annunciato ho aggiunto una sezione sulla gestione dei branch. Tutti gli indirizzi segnalati sono sempre validi, compreso il PDF (che ho aggiornato): http://elubuntu.altervista.org/LaTeX/git4latex.pdf

Una rapida annotazione: nel paragrafo 3.1 della guida attualmente online la riga in rosso nel seguente blocco di codice`~$ mkdir progetto
~/ progetto$ cd progetto
~/ progetto$ touch np_main .tex
~/ progetto$ git init
~/ progetto$ git add .
~/ progetto$ git commit -am ” Inizializzazione del nuovo
progetto “`
andrebbe corretta con la linea in blu del seguente:
`~$ mkdir progetto
~$ cd progetto
~/ progetto$ touch np_main .tex
~/ progetto$ git init
~/ progetto$ git add .
~/ progetto$ git commit -am ” Inizializzazione del nuovo
progetto “`
😉
LuCa

Una rapida annotazione: nel paragrafo 3.1 della guida attualmente online la riga in rosso nel seguente blocco di codice`~$ mkdir progetto
~/ progetto$ cd progetto
~/ progetto$ touch np_main .tex
~/ progetto$ git init
~/ progetto$ git add .
~/ progetto$ git commit -am ” Inizializzazione del nuovo
progetto “`
andrebbe corretta con la linea in blu del seguente:
`~$ mkdir progetto
~$ cd progetto
~/ progetto$ touch np_main .tex
~/ progetto$ git init
~/ progetto$ git add .
~/ progetto$ git commit -am ” Inizializzazione del nuovo
progetto “`
😉
LuCa

Grazie 😀

Ciao, vorrei chiederti se preferisci github o gitorious quale servizio di hosting.
Inoltre, non potresti inserire nel repository anche il PDF già compilato?

Ed ancora, se volessi apportare modifiche al tuo sorgente originale come potrei fare?
In altre parole, volendo collaborare al progetto senza clonarlo (ho già installato git su una macchina Linux), cosa si dovrebbe fare?
Grazie

Ciao, vorrei chiederti se preferisci github o gitorious quale servizio di hosting.

Personalmente ho provato solo gitourious e solo per questo progetto, non posso fare paragoni, una cosa che ho notato però è che github ha una buona documentazione, gitorious non ce l’ha proprio (o almeno non l’ho trovata proprio, su github invece è facilmente accessibile) infatti dianoia e io abbiamo avuto delle difficoltà per iniziare a collaborare 🙁
Github comunque è il più grande servizio per i progetti git, alcune stime dicono che oltre il 60% dei progetti git è ospitato da questo portale.

Inoltre, non potresti inserire nel repository anche il PDF già compilato?

Non voglio includere il documento all’interno del repository git perché appesantirebbe il repository (a ogni revisioni bisognerebbe tracciare le modifiche a un file binario) e sarebbe un inutile doppione (già si tracciano le modifiche del sorgente, non serve controllare anche le modifiche del documento) e, per finire, condividendo il repository il documento potrebbe essere compilato in maniera differente da ognuno (per esempio a causa di versioni differenti dei pacchetti usati o del motore TeX) producendo differenza fra le revisioni inutili e lunghe. Nei repository dei software si condivide il sorgente, non il programma stesso.
Una possibilità sarebbe quella di caricare il PDF come “file esterno al progetto” ma non so come si faccia né se sia possibile farlo (e l’assenza di documentazione su gitorious di certo non aiuta) 😳

Ed ancora, se volessi apportare modifiche al tuo sorgente originale come potrei fare?
In altre parole, volendo collaborare al progetto senza clonarlo (ho già installato git su una macchina Linux), cosa si dovrebbe fare?
Grazie

Cosa intendo per collaborare senza clonare? Per collaborare devi clonare il repository 😀

Ed ancora, se volessi apportare modifiche al tuo sorgente originale come potrei fare?
In altre parole, volendo collaborare al progetto senza clonarlo (ho già installato git su una macchina Linux), cosa si dovrebbe fare?
Grazie

Cosa intendo per collaborare senza clonare? Per collaborare devi clonare il repository 😀

Innanzi tutto grazie per le dettagliate risposte.
Intendo questo:
Ammetti di essere davanti ad un progetto collaborativo, dove un team lavora contemporaneamente a diversi file via web.
Tecnicamente, come fanno diverse persone ad avere accesso alla gestione dello stesso unico repository che si evolve magari rapidamente, nel tempo?

La mia intenzione è duplice: correggere alcuni errori del tuo sorgente ed avviare un progetto collaborativo. In entrambe i casi, più persone devono poter lavorare sullo stesso repository. Clonando i repo infatti, si perde il fatto stesso di lavorare nello stesso team.
Cosa ne pensi?

[quote]Ed ancora, se volessi apportare modifiche al tuo sorgente originale come potrei fare?
In altre parole, volendo collaborare al progetto senza clonarlo (ho già installato git su una macchina Linux), cosa si dovrebbe fare?
Grazie

Cosa intendo per collaborare senza clonare? Per collaborare devi clonare il repository 😀

Innanzi tutto grazie per le dettagliate risposte.
Intendo questo:
Ammetti di essere davanti ad un progetto collaborativo, dove un team lavora contemporaneamente a diversi file via web.
Tecnicamente, come fanno diverse persone ad avere accesso alla gestione dello stesso unico repository che si evolve magari rapidamente, nel tempo?
[/quote]
Questo è il bello dei sistemi di revisione: pensano loro a correggere (se riescono a farlo) i conflitti tra le revisioni. Un modo utile di lavorare comunque è creare un proprio branch: lavori nel tuo “spazio”, non hai conflitti con nessuno, quando pensi che il lavoro sia pronto chiedi di effettuare il merge nel branch principale e anche in questo caso git prova a gestire i conflitti. Se non ce la fa deve intervenire manualmente uno dei manutentori del ramo in cui si vuole confluire.

Questo è il bello dei sistemi di revisione: pensano loro a correggere (se riescono a farlo) i conflitti tra le revisioni. Un modo utile di lavorare comunque è creare un proprio branch: lavori nel tuo “spazio”, non hai conflitti con nessuno, quando pensi che il lavoro sia pronto chiedi di effettuare il merge nel branch principale e anche in questo caso git prova a gestire i conflitti. Se non ce la fa deve intervenire manualmente uno dei manutentori del ramo in cui si vuole confluire.

Ah, capito. La parala magica è merge dunque.
Grazie.

Oggi ho scaricato la versione di Git per Windows, ed ho anche effettuato la registrazione su Gitorious.
Voglio capire delle cose:
1) Cosa è la chiave ssh?
2) Cosa significa lavorare in locale?
3) Si lavora ad un progetto sul proprio Pc che poi si uppa sul sito e gli altri possono vederlo e modificarlo?

Queste sono le prime. Preparatevi al peggio 😆 (scherzo)

Grazie,
ansys.

Oggi ho scaricato la versione di Git per Windows, ed ho anche effettuato la registrazione su Gitorious.
Voglio capire delle cose:
1) Cosa è la chiave ssh?
2) Cosa significa lavorare in locale?
3) Si lavora ad un progetto sul proprio Pc che poi si uppa sul sito e gli altri possono vederlo e modificarlo?

Queste sono le prime. Preparatevi al peggio 😆 (scherzo)

Grazie,
ansys.

1 – la chiave ssh rende accessibile il tuo repository on-line solo a te, insomma garantisce la sicurezza. Ricordo che quando ho creato il mio account su github da ubuntu non sono riuscito alla prima a generare ed autenticare la chiave, ma poi è andato tutto liscio. Può darsi che github usi un altra tecnologia rispetto ad ssh

2 – se lavori in locale stai semplicemente modificando i file sul repository nell’hard disk sul tuo pc. I commit aggiorneranno infatti solo quello. Se poi fai un commit remote si aggiornerà anche il repo internet sulla base di quello locale (in teoria penso si possa definire il repo on-line un mirror di quello locale).

3 – il repo on-line può essere modificato solo dal proprietario. In base poi al tipo di servizio fornito (i.e. gitorius o github), il repo può essere pubblico o privato.
In genere i servizi gratuiti sono anche quelli pubblici e questo significa che tutti i file del tuo repo non solo possono essere letti, ma possono essere anche clonati in un repo diverso ed utilizzati con lo stesso tipo di “licenza” d’uso.

Dai post precedenti ho capito che è anche possibile fondere insieme due repo clonati in modo da consentire una sorta di lavoro di squadra.

Bye

1 – la chiave ssh rende accessibile il tuo repository on-line solo a te, insomma garantisce la sicurezza. Ricordo che quando ho creato il mio account su github da ubuntu non sono riuscito alla prima a generare ed autenticare la chiave, ma poi è andato tutto liscio. Può darsi che github usi un altra tecnologia rispetto ad ssh

Ok, ma se voglio che qualche persona collabori al mio progetto può essere passata, giusto?

2 – se lavori in locale stai semplicemente modificando i file sul repository nell’hard disk sul tuo pc. I commit aggiorneranno infatti solo quello. Se poi fai un commit remote si aggiornerà anche il repo internet sulla base di quello locale (in teoria penso si possa definire il repo on-line un mirror di quello locale).

Perfetto, dubbio sciolto. Però non ho capito l’effettiva utilità di tutto questo. Emacs salva di default un backup per poter ripristinare il file ad una versione precedente. Così anche WinEdt (sembra passato già tanto tempo…). Lavorare da soli con Git a cosa serve, in ultima analisi?

3 – il repo on-line può essere modificato solo dal proprietario. In base poi al tipo di servizio fornito (i.e. gitorius o github), il repo può essere pubblico o privato.
In genere i servizi gratuiti sono anche quelli pubblici e questo significa che tutti i file del tuo repo non solo possono essere letti, ma possono essere anche clonati in un repo diverso ed utilizzati con lo stesso tipo di “licenza” d’uso.

Qui vado in confusione. Se al punto (1) abbiamo detto che la ssh key serve per la sicurezza, come fa ad essere pubblico o privato un repo? Dipende dal sito di hosting?

Dai post precedenti ho capito che è anche possibile fondere insieme due repo clonati in modo da consentire una sorta di lavoro di squadra.

È proprio questo che mi interessa… 😉

Grazie,
ansys.

Il repository on line può essere modificato solo da chi ne ha le credenziali, quindi l’accesso è privato ma i dati sono pubblici (generalmente è così per gli hosting gratuiti).
In altre parole, la chiave ssh rende per tutti i dati di sola lettura tranne a te che hai l’accesso anche in scrittura.

Credo però, in qualità di utente LaTeX, che sia importante chiarire cosa ci si aspetta: una struttura verticale in cui ogni modifica viene sottoposta all’amministratore del progetto che ha l’onere di approvarle e di risolvere eventuali conflitti tra modifiche apportate sulle medesime righe di codice? O una struttura libera e distribuita in cui ciascuno ha il diritto di far ciò che vuole ma in cui ogno passaggio, ogno modifca deve essere tracciabile ricostruibile ed associabile ad un determinato utente? Credo che chiarito questo punto, e scelto se si va in direzione di un wiki collaborativo o di un libro in senso più tradizionale, anche la risposta potrebbe essere più semplice.

Perfettamente d’accordo. Hai centrato il nocciolo della tematica LaTeX/git.
Credo che non esiste una risposta univoca perché dipende dal progetto che si sta portando avanti.
Se si sta scrivendo uno stesso documento un coordinatore è necessario, se invece ciascuno è responsabile di una propria sezione, ognuno è responsabile di se stesso.
In pratica ogni sezione diviene un documento autonomo.
Un buon esempio “misto” credo sia la nostra rivista ArSTeXnica, dove ogni articolo è un documento indipendente uno dall’altro ma che potrebbe essere prodotto da uno o più autori.

Interessanti anche i link che hai postato.
Grazie e saluti.

Grazie per le risposte.
Sto cercando di capirci qualche cosa, ma non ci riesco.
Ho clonato il repo git4latex. Ora voglio ricrearlo in locale con
`git clone git://gitorious.org/ansys/git4latex/ansyss-git4latex.git`
ma ottengo il messaggio di errore:
`Cloning into ansyss-git4latex…
fatal: The remote end hung up unexpectedly`
Perché?

Grazie,
ansys.

Grazie per le risposte.
Sto cercando di capirci qualche cosa, ma non ci riesco.
Ho clonato il repo git4latex. Ora voglio ricrearlo in locale con
`git clone git://gitorious.org/ansys/git4latex/ansyss-git4latex.git`
ma ottengo il messaggio di errore:
`Cloning into ansyss-git4latex…
fatal: The remote end hung up unexpectedly`
Perché?

Grazie,
ansys.

A me funziona 😕

Grazie per le risposte.
Sto cercando di capirci qualche cosa, ma non ci riesco.
Ho clonato il repo git4latex. Ora voglio ricrearlo in locale con
`git clone git://gitorious.org/ansys/git4latex/ansyss-git4latex.git`
ma ottengo il messaggio di errore:
`Cloning into ansyss-git4latex…
fatal: The remote end hung up unexpectedly`
Perché?

Grazie,
ansys.

A me funziona 😕

ho risolto ora con `git clone git://gitorious.org/git4latex/ansyss-git4latex.git`

Ora il problema è un altro: se faccio qualche modifica in locale e ne voglio fare un backup on-line, con i comandi della guida, non ci riesco.

Grazie,
ansys.

Ora ho capito perché a me funzionava: avevo dato il comando
`git clone git://gitorious.org/~ansys/git4latex/ansys-g4t.git ansys-g4t`
(c’era un ~ di differenza con il tuo).

Che comando dai aggiornare il repository online?

Ora ho capito perché a me funzionava: avevo dato il comando
`git clone git://gitorious.org/~ansys/git4latex/ansys-g4t.git ansys-g4t`
(c’era un ~ di differenza con il tuo).

Che comando dai aggiornare il repository online?

Il fatto è che facendo copia e incolla da gitorious si perde la tilde per la strada.
Dopo aver fatto una modifica al file scrivo:
`git remote add origin git@gitorious.org:~ansys/git4latex/ansys-g4t.git`
e qui non ottengo nessuna segnalazione, però dando `git push origin master
`
ottengo:`$ git push origin master
fatal: protocol error: expected sha/ref, got '☻
———————————————-
The git:// protocol is read-only.

Please use the push url as listed on the reposit
———————————————-'`

Grazie,
ansys.

P.s.: devo fare pratica con queste cose… tu sai il perché 😆

Ora ho capito perché a me funzionava: avevo dato il comando
`git clone git://gitorious.org/~ansys/git4latex/ansys-g4t.git ansys-g4t`
(c’era un ~ di differenza con il tuo).

Se sei Windows quella potrebbe essere la causa (su Linux non ho problemi)

Il fatto è che facendo copia e incolla da gitorious si perde la tilde per la strada.
Dopo aver fatto una modifica al file scrivo:
`git remote add origin git@gitorious.org:~ansys/git4latex/ansys-g4t.git`
e qui non ottengo nessuna segnalazione, però dando `git push origin master
`
ottengo:`$ git push origin master
fatal: protocol error: expected sha/ref, got '☻
———————————————-
The git:// protocol is read-only.

Please use the push url as listed on the reposit
———————————————-'`

Grazie,
ansys.

Prova con
`git remote add ansys-g4t git://gitorious.org/~ansys/git4latex/ansys-g4t.git`
come scritto qui http://gitorious.org/~ansys/git4latex/ansys-g4t (facendo cli sul punto interrogativo vicino all’indirizzo)

P.s.: devo fare pratica con queste cose… tu sai il perché 😆

Avevo immaginato 😉

Ricapitoliamo.
1 – Ho clonato il repo originale su gitorious;
2 – Ho clonato il mio repo in locale con
`git clone git://gitorious.org/git4latex/ansyss-git4latex.git`
3 – Ho fatto una modifica di prova nel file git4latex.tex
4 – Ho fatto un commit con:
`git commit -am “Modifica di prova”`
ed ottengo
`*******@**** ~/ansys-g4t (master)
$ git commit -am “Modifica di prova”
[master bbe649e] Modifica di prova
1 files changed, 1 insertions(+), 1 deletions(-)`

Il problema ora è capire perché non riesco a fare gli aggiornamenti del lavoro sul repo on-line.
La tilde continua a perdersi tra il copia e incolla e non so come farla.
Per fare il back-op on-line faccio:`$ git push origin master`
ma ottengo:`fatal: protocol error: expected sha/ref, got '☻
———————————————-
The git:// protocol is read-only.

Please use the push url as listed on the repository page.
———————————————-'`

Come posso risolvere?
Grazie,
ansys.

Alla fine bastava googolare un po’.
Il problema è dovuto al fatto che nel file .git/config ci sono gli url sbagliati. Basta cambiarli, nel mio caso per esempio, così:
`git://gitorious.org/~ansys/git4latex/ansys-g4t.git`
in
`url = git@gitorious.org:~ansys/git4latex/ansys-g4t.git`
e le modifiche vanno al posto loro anche on-line.

Grazie Elrond, dammi ancora un po’ di tempo e quel discorso lo continuiamo su gitorious tramite Git!

Grazie ancora,
ansys.

Salve a tutti.
Se voglio importare delle modifiche nel mio repo da un altro repo, come posso fare? Devo prima clonare il secondo repo sul mio PC e poi effettuare un merge?

Grazie
Orlando

Salve a tutti.
Se voglio importare delle modifiche nel mio repo da un altro repo, come posso fare? Devo prima clonare il secondo repo sul mio PC e poi effettuare un merge?

Grazie
Orlando

Quasi, la seconda parte è giusta. Non devi esattamente clonare (altrimenti ti crea una nuova cartella, sarebbe in pratica un nuovo repository) ma devi creare un nuovo branch con `git branch [nome del branch]’ e visitarlo con `git checkout [nome del branch]’ (queste due operazioni possono essere abbreviate nell’unico comando `git checkout -B [nome del branch]’ se il branch non esiste). Dopo di ciò in questo branch scarichi con `git pull’ quello che ti serve e poi potrai effettuare il merge di tutto questo ramo all’interno del ramo principale master (o in quello che ti interessa) oppure selezionare solo alcuni commit con il `cherry-picking’.

Comunque se qualcuno ti fa la richiesta di merge su gitorious, nella pagina del `merge request’ ci sono in basso a destra tutte le indicazioni dettagliate su come effettuare l’operazione.

P. S. sbaglio o avevi già risolto da solo?

Salve a tutti.
Se voglio importare delle modifiche nel mio repo da un altro repo, come posso fare? Devo prima clonare il secondo repo sul mio PC e poi effettuare un merge?

Grazie
Orlando

Quasi, la seconda parte è giusta. Non devi esattamente clonare (altrimenti ti crea una nuova cartella, sarebbe in pratica un nuovo repository) ma devi creare un nuovo branch con `git branch [nome del branch]’ e visitarlo con `git checkout [nome del branch]’ (queste due operazioni possono essere abbreviate nell’unico comando `git checkout -B [nome del branch]’ se il branch non esiste). Dopo di ciò in questo branch scarichi con `git pull’ quello che ti serve e poi potrai effettuare il merge di tutto questo ramo all’interno del ramo principale master (o in quello che ti interessa) oppure selezionare solo alcuni commit con il `cherry-picking’.

Comunque se qualcuno ti fa la richiesta di merge su gitorious, nella pagina del `merge request’ ci sono in basso a destra tutte le indicazioni dettagliate su come effettuare l’operazione.

P. S. sbaglio o avevi già risolto da solo?

Si, diciamo che avevo già risolto con il metodo che avevo scritto, ma le tue indicazioni mi serviranno in futuro.

Grazie
Orlando

Scusate l'(h)orrore ortografico, ho corretto nel mio messaggio 😀

Salve a tutti.

È possibile annullare (o modificare) un commit?

Grazie
Orlando

ansys” post=66842Salve a tutti.

È possibile annullare (o modificare) un commit?

Grazie
Orlando

Sì, l’ho spiegato nelle modifiche che ho fatto un mesetto fa nel mio branch della guida: http://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex Non ho prodotto un PDF aggiornato, se lo vuoi provvedo al più presto, comunque puoi scaricare un archivio del codice sorgente presente nel branch qui: http://gitorious.org/git4latex/elrondgits-git4latex/archive-tarball/elrond

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

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!

Elrond” post=80964

Chiedo 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!

Ehm…
Non è che, quasi quasi, conviene creare il repo sotto guitex?
Sarebbe una nuova guida tematica…
R.

robitex” post=80965

[quote=”antonio.macrì” post=80949]Chiedo 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!

Ehm…
Non è che, quasi quasi, conviene creare il repo sotto guitex?
Sarebbe una nuova guida tematica…
R.[/quote]Ho già creato il repo sotto il mio account: https://github.com/giordano/guidagit ma se l’intenzione è quella di fare una nuova guida tematica ci vuole poco a spostare tutto il gruppo del GuIT, mi basta cambiare il repository remoto. Sbaglio o non mi è possibile creare nuovi repo nel gruppo?

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.

Ho scaricato l’archivio .zip, l’ho esploso sulla scrivania e ho lanciato make:

`
! LaTeX Error: File `guidatematica.cls' not found.
…
$ sutlmgr info guidatematica
tlmgr: package repository http://ftp.uniRoma2.it/TeX/systems/texlive/tlnet
tlmgr: cannot find package guidatematica
`

Suggerisco:

1. inserire ‘guidatematica.cls’ in ogni repo git, in modo da garantire la compilazione senza doversi andare a cercare le classi necessarie chissà dove;
2. in alternativa inserire nel Makefile un messaggio che indichi dove scaricare ‘guidatematica.cls’
3. caricare ‘guidatematica.cls’ su CTAN

Grazie, ciao.

p.s. – Da dove scarico guidatematica.cls?

Sam Qasbah” post=80969Da dove scarico guidatematica.cls?

https://github.com/GuITeX/guidetematiche

Abbiamo già discusso l’inclusione della classe “guidatematica” nei repo in altri filoni. Io ho i sorgenti di 3 o 4 guide tematiche, non vedo l’utilità per me di ricopiare ogni volta tutti i file della classe in ogni cartella quando esiste una cosa così utile chiamata “albero locale” che serve proprio per rendere disponibile i file una classe a tutto il sistema, tanto più che se la classe dovesse essere aggiornata dovrei cambiare ogni volta tutte le classi in tutte le cartelle, sfruttando l’albero locale basta una sola modifica. Inoltre se la classe facesse parte del repo, a ogni aggiornamento di questa si dovrebbe fare un commit apposito su tutti i repo di tutte le guide che si appoggiano alla classe (a meno di usare sottomoduli git).

Elrond” post=80971 … quando esiste una cosa così utile chiamata “albero locale” …

git4latex si trova nel repo di Mosè, guidetematiche.cls si trova nel repo guitex: cosa 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). In ogni caso, io vorrei solo compilare un documento LaTeX. La procedura standard è quella di caricare le classi di uso comune su CTAN: perchè questa no?

Comunque state facendo un bel lavoro.

Grazie e ciao.

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

Elrond” post=80973L’albero locale è l’albero locale della distribuzione TeX Live…

Ah, quell’albero locale? Il tuo albero locale? E cosa c’entra col fatto che una classe di uso comune è raggiungibile solo da pochi iniziati? Vabbè, la pianto qui. Ciao.

Sam Qasbah” post=80974

L’albero locale è l’albero locale della distribuzione TeX Live…

Ah, quell’albero locale? Il tuo albero locale? E cosa c’entra col fatto che una classe di uso comune è raggiungibile solo da pochi iniziati? Vabbè, la pianto qui. Ciao.

Ah ah ah.
Ma no. Non è una classe per pochi iniziati.
Si tratta della classe messa a punti da Claudio in collaborazione per comporre le guide tematiche.
La classe si trova in un repository su github.
La scarichi, la copi nell’albero locale.
Poi scarichi i sorgenti della guida e la compili.
Ma non è questa la modalitá per ottenere la guida.
Infatti i pdf si scaricano in un attimo direttamente dal siti del GuIT.
In questo momenti la guida tematica a git si trova ai primi stadi di sviluppo.
Invece, tutto quello che trovi su github nel gruppo GuITeX è li per permettere a tutti di contribuire alle guide.
Le guide tematiche diventano a sviluppo aperto propeio con git.
Ciao.
R.

robitex” post=80975
Ma no. Non è una classe per pochi iniziati.
Si tratta della classe messa a punti da Claudio in collaborazione per comporre le guide tematiche.
La classe si trova in un repository su github.
La scarichi, la copi nell’albero locale.
Poi scarichi i sorgenti della guida e la compili.

Qui sul forum vi siete accorti che non ho fatto il liceo classico e vi approfittate di me.

@Elrond: quanto scritto su Windows è un po’ obsoleto: git, ora, si scarica comodamente da http://git-scm.com/ (anche se uso quello di cygwin).

Ciao,
Orlando

Sam Qasbah” post=80978

Ma no. Non è una classe per pochi iniziati.
Si tratta della classe messa a punti da Claudio in collaborazione per comporre le guide tematiche.
La classe si trova in un repository su github.
La scarichi, la copi nell’albero locale.
Poi scarichi i sorgenti della guida e la compili.

Qui sul forum vi siete accorti che non ho fatto il liceo classico e vi approfittate di me.

Sam, se sei andato nel repository avrai visto che guidatematica.cls non è l’unico file lì presente; mettere l’intero pacchetto guidatematica su CTAN non sarebbe, secondo me, una buona idea, perché essa è funzionale solo per il nostro gruppo GuIT; nello stesso tempo se fosse su CTAN, non potrebbe essere soggetto a modifiche o arricchimenti collaborativi.

Nello stesso tempo c’è il file guidatematica-doc.pdf (con il suo sorgente, sempre suscettibile di interventi collaborativi) che dice esattamente che cosa fare con i vari file che costituiscono il pacchetto; in altre parole non basta installare guidatematica.cls da qualche parte, perché bisogna installare anche tutti gli altri file.

Dove installarli? Il problema è sempre lo stesso che si ha con qualunque altro software legato al sistema TeX, ma non distribuito tramite TeX Live o MiKTeX; infatti non è opportuno installare i file del pacchetto guidatematica negli alberi del sistema TeX perché ad ogni aggiornamento di TeXLive all’edizione dell’anno successivo, o di MiKTeX ad un numero di versione successivo, gli alberi di sistema verrebbero riscritti e anche, eventualmente cancellati quelli preesistenti oppure resi inaccessibili da una diversa impostazione del PATH della macchina.

Restano solo due alberi possibili che non subiscono la sorte degli altri alberi di sistema: (1) l’albero locale (concetto sicuramente ben definito con TeX Live, non so se sia ben definito con MiKTeX) e l’albero personale (concetto definito sia con TeX Live sia con MiKTeX). La differenza è che i file memorizzati nell’albero locale sono accessibili a tutti gli utenti della macchina, mentre i file memorizzati nell’albero personale sono accessibili solo all’unico proprietario. All’atto pratico la maggior parte dei PC di qualunque marca e con qualunque sistema operativo sono usati da una sola persona, qundi in paratica non c’è nessuna differenza fra i due tipi di albero, ma l’effetto sarebbe drammaticamente diverso per una moltitudine di utenti.

Con TeX Live l’albero personale non è predefinito, mentre l’albero locale lo è; all’albero locale vi accede solo l’amministratore della macchina o il superuser che abbia disponibilità della password di amministratore (concetto chiaro sul Mac e su Linux; molto meno chiaro su Windows); all’albero locale vi accede solo il proprietario, ma il proprietario deve crearselo esplicitamente nella sua “HOME”; fortunatamante anche questo è un concetto ben definito con tutti i sistemi operativi; esso va creato con la radice ~/texmf sulle macchina Linux, con la radice ~/Library/texmf sul Mac, e con C:\Users\\texmf su una versione di Windows sufficientemente recente (vedi sull’Arte le differenti Home per WinXP, WinVista, Win7, Win8). Quando si modifica il contenuto dell’albero personale non è necessario aggiornare il database dei nomi dei file con TeX Live. Con MiKTeX invece oltre a doverlo elencare fra gli alberi di MiKTeX sembra che sia necessario aggironare il database dei nomi dei file.

Ora, quanto ho scritto non dovrebbe esserti indecifrabile, perché so che ti sei cimentato anche con Plain TeX e quindi hai una certa esperienza di calcolatore e di sistema TeX; ma non dipende dal fatto che tu abbia on non abbia fatto il classico; è che l’informatichese è complicato e spesso non si capiscono vicendevolmente nemmeno gli informatici, figuriamoci noi poveri mortali. Tanto per fare un esempio, io ho fatto il classico ma non capisco nemmeno la metà di quello che viene scritto in questo filone del forum in merito a git. 🙁

Ciao e Buon Anno
Claudio

Ciao a tutti.
Penso che valga la pena imparare ad usare git.
E spero che la relativa guida tematica ci permetta di farlo bene.
Potremo creare un progetto anche per distribuire template LaTeX.
Penso che il 2013 ci permetterà di sviluppare questo sistema di collaborazione ed anche di passare alla nuova versione del motore del nostro sito.
Due obiettivi importanti per il gruppo assieme all’organizzazione del prossimo meeting.
Buon anno a tutti ed al GuIT.
R.

OldClaudio” post=80980…
Ora, quanto ho scritto non dovrebbe esserti indecifrabile, perché so che ti sei cimentato anche con Plain TeX e quindi hai una certa esperienza di calcolatore e di sistema TeX; ma non dipende dal fatto che tu abbia on non abbia fatto il classico; è che l’informatichese è complicato e spesso non si capiscono vicendevolmente nemmeno gli informatici, figuriamoci noi poveri mortali. Tanto per fare un esempio, io ho fatto il classico ma non capisco nemmeno la metà di quello che viene scritto in questo filone del forum in merito a git.
Claudio

Il mio riferimento al liceo classico era una risposta [oscuramente] ironica al tono pedagogico usato da robitex nella sua risposta. Tanto per chiarire che non soffro di complessi di inferiorità ho fatto lo scientifico (con parecchi nove e dieci sui “quadri”), mi sono ben laureato, svolgo con onore una professione difficile.

Effettivamente ora mi oriento bene con il TeX, leggo senza difficoltà i formati scritti dai guru, scrivo formati funzionanti e dagli effetti tipograficamente piacevoli. In particolare so cosa è l’albero locale, l’albero personale, eccetera.

La tua risposta è piena di buon senso e in particolare ha risolto il mio dubbio sul perchè non pubblicare su CTAN una classe usata da molti utenti. Resto dell’opinione che se un documento pubblicato su un repo privato (git4latex) necessita per la compilazione di un package pubblicato su un altro repo privato (guidatematica.cls), diventa necessario che il collegamento al package “servente” sia esplicito e inequivoco. Ovviamente è solo una opinione personale.

Auguro a tutti voi che avete fatto il liceo classico di passare il capodanno bevendo champagne, ballando con donne bellissime e facendo i trenini al suono di “pais tropical”.

Buon anno.

Domanda: se propongo un merge, chi lo riceve, può anche scegliere quali commit applicare e quali no?

Grazie,
Orlando

ansys” post=80991Domanda: se propongo un merge, chi lo riceve, può anche scegliere quali commit applicare e quali no?

Grazie,
Orlando

Sicuramente si può fare il cherry-picking, non so se sia possibile fare un merge di determinati commit (che in realtà mi sembra la stessa cosa)

Elrond” post=80992

Domanda: se propongo un merge, chi lo riceve, può anche scegliere quali commit applicare e quali no?

Grazie,
Orlando

Sicuramente si può fare il cherry-picking, non so se sia possibile fare un merge di determinati commit (che in realtà mi sembra la stessa cosa)

Grazie mille. Questa cosa va studiata perché, se modifico delle cose e propongo un merge, alcune modifiche possono essere utili per me ma non per chi riceve la richiesta del merge.

Grazie,
Orlando

Sam Qasbah” post=80990

…
Ora, quanto ho scritto non dovrebbe esserti indecifrabile, perché so che ti sei cimentato anche con Plain TeX e quindi hai una certa esperienza di calcolatore e di sistema TeX; ma non dipende dal fatto che tu abbia on non abbia fatto il classico; è che l’informatichese è complicato e spesso non si capiscono vicendevolmente nemmeno gli informatici, figuriamoci noi poveri mortali. Tanto per fare un esempio, io ho fatto il classico ma non capisco nemmeno la metà di quello che viene scritto in questo filone del forum in merito a git.
Claudio

Il mio riferimento al liceo classico era una risposta [oscuramente] ironica al tono pedagogico usato da robitex nella sua risposta. Tanto per chiarire che non soffro di complessi di inferiorità ho fatto lo scientifico (con parecchi nove e dieci sui “quadri”), mi sono ben laureato, svolgo con onore una professione difficile.

Effettivamente ora mi oriento bene con il TeX, leggo senza difficoltà i formati scritti dai guru, scrivo formati funzionanti e dagli effetti tipograficamente piacevoli. In particolare so cosa è l’albero locale, l’albero personale, eccetera.

La tua risposta è piena di buon senso e in particolare ha risolto il mio dubbio sul perchè non pubblicare su CTAN una classe usata da molti utenti. Resto dell’opinione che se un documento pubblicato su un repo privato (git4latex) necessita per la compilazione di un package pubblicato su un altro repo privato (guidatematica.cls), diventa necessario che il collegamento al package “servente” sia esplicito e inequivoco. Ovviamente è solo una opinione personale.

Auguro a tutti voi che avete fatto il liceo classico di passare il capodanno bevendo champagne, ballando con donne bellissime e facendo i trenini al suono di “pais tropical”.

Buon anno.

Non c’è bisogno di dire che il mio tono non voleva essere pedagogico vero?
Mi è solo sembrato giusto dirti che i file sul progetto github sono intesi per la collaborazione su guide tematiche ed altro. Non sono privati ma tutt’altro…
Buon anno.
R.

ansys” post=80979 @Elrond: quanto scritto su Windows è un po’ obsoleto: git, ora, si scarica comodamente da http://git-scm.com/ (anche se uso quello di cygwin).

Ciao,
Orlando

@Elrond: tra i vari messaggi ti (ri)segnalo questo, che forse si è perso 🙂

Ciao,
Orlando

Ho letto la guida e mi sembra molto chiara anche per uno negato come me. Complimenti.
L’unico capitolo che mi sembra un po’ affrettato è il terzo, nel quale mancano proprio le spiegazioni.
Ho trovato delle sviste (un paio di frasi lasciate in sospeso), ma non avendo avuto l’intelligenza di segnarmele, sarò costretto a rileggere tutto per rintracciarle.
Invece, a proposito del branch si legge che il comando per generare un branch è [tt]git branch nomedelramo[/tt]. Più in basso si legge “In alternativa a [tt]git checkout nomedelramo[/tt], per creare un nuovo ramo si può usare il comando [tt]git checkout -b nomedelramo[/tt]”… Il senso del collegamento l’ho capito, ma credo che la frase sia un po’ ambigua, perché si intende che checkout serva a creare un nuovo branch.

Richiesta: si potrebbe aggiungere in appendice una lista dei comandi con descrizione breve da usare come promemoria?

Domanda forse un po’ offtopic: ma è possibile inibire la visualizzazione di un progetto a chi non è autorizzato?

Ciao e grazie.

Liverpool” post=86773Ho letto la guida e mi sembra molto chiara anche per uno negato come me. Complimenti.
L’unico capitolo che mi sembra un po’ affrettato è il terzo, nel quale mancano proprio le spiegazioni.
Ho trovato delle sviste (un paio di frasi lasciate in sospeso), ma non avendo avuto l’intelligenza di segnarmele, sarò costretto a rileggere tutto per rintracciarle.

Ogni contributo è ben accetto, soprattutto per sviste così colossali come frasi lasciate a metà 😳

Liverpool” post=86773Invece, a proposito del branch si legge che il comando per generare un branch è [tt]git branch nomedelramo[/tt]. Più in basso si legge “In alternativa a [tt]git checkout nomedelramo[/tt], per creare un nuovo ramo si può usare il comando [tt]git checkout -b nomedelramo[/tt]”… Il senso del collegamento l’ho capito, ma credo che la frase sia un po’ ambigua, perché si intende che checkout serva a creare un nuovo branch.

Si possono creare nuovi rami in due modi: [tt]git branch nomebranch[/tt] e [tt]git checkout -b nomebranch[/tt] (differenza: il primo crea il ramo ma rimane in quello attuale, il secondo lo crea e lo visita): questo è chiaro o è da spiegare meglio?

Liverpool” post=86773Richiesta: si potrebbe aggiungere in appendice una lista dei comandi con descrizione breve da usare come promemoria?

Certo, è una buona idea, prendo nota

Liverpool” post=86773Domanda forse un po’ offtopic: ma è possibile inibire la visualizzazione di un progetto a chi non è autorizzato?

Si può creare un repository privato: su github sono a pagamento, su bitbucket sono gratuiti

Elrond” post=86774Si possono creare nuovi rami in due modi: [tt]git branch nomebranch[/tt] e [tt]git checkout -b nomebranch[/tt] (differenza: il primo crea il ramo ma rimane in quello attuale, il secondo lo crea e lo visita): questo è chiaro o è da spiegare meglio?

E’ chiaro, ma dalla frase sembra (almeno a me) che [tt]git checkout nomedelramo[/tt] sia un modo per generare un nuovo ramo (“in alternativa a [tt]git checkout nomedelramo[/tt]”). Invece il senso era, se ho capito bene, che se si aggiunge [tt]-b[/tt] al comando precedente, si può generare un nuovo ramo.

Più tardi me la rileggo alla ricerca delle due frasi in sospeso.

Ciao

Elrond” post=86774Ogni contributo è ben accetto, soprattutto per sviste così colossali come frasi lasciate a metà 😳

Penso di averle rintracciate:

• a pag. 15
  

  Mi accade con estrema frequenza…

• a pag. 27
  

  Non è necessario ettettuare il merge…

Ciao

@Liverpool: continuo una discussione nata altrove, qui è meno off topic

Elrond” post=86757La cosa più fastidiosa è che qualche mese fa su Github hanno avuto l’infelice idea di rimuovere il servizio di caricamento di file esterni al repository (accampando scuse secondo me abbastanza sciocche, ma tant’è).

Proprio due giorni fa Github ha aggiunto una nuova funzione che permette di caricare file binari esterni al repository: https://github.com/blog/1547-release-your-software La funzione in se è carina, il fatto che sia legato ai tag permette di recuperare facilmente vecchie versioni di software, o documenti nel nostro caso, però mi piacerebbe anche caricare file quando mi pare e non legati a una versione particolare. Comunque questa nuova funzione è sicuramente meglio di niente.