La guerra dei cloni

Dopo il piccolo grattacapo di evolution-data-server (non evolution in sé, ma evolution-data-server) e il piccolo problema del file col nome sbagliato, ora comunque corretto (era tardi, eravamo stanchi e stavamo cercando di dare una soluzione rapida e indolore; pare ora che i permessi siano errati sul file, ma in teoria dovrebbe funzionare lo stesso, più tardi controllo), adesso per me arrivano le rogne.

Rogne… oddio… non è proprio una rogna, ma una gran rottura di palle.

Perché questo? Perché dato che, diciamo, un amico di un mio amico ha un computer un po’ piccolino (un Dell Mini 9), non può certo clonare i repository di GNOME per farne i push (eh… bisogna imparare nuova terminologia qui!), no, tocca al sottoscritto questa volta…

Come anche i sassi sanno, GNOME ora è passato a git (ora, cioè… si sa se il passaggio è finito? è da ieri che va avanti e nessuno ha ancora detto nulla…), il DVCS che tutto fa e tutto ha, onnisciente e onnipotente, divino e superiore, ma che non è in grado di clonare una singola directory per fare un semplice commit+push (è un problema di tutti i DVCS comunque), pare, ma qui mi rifaccio al caro e vecchio “dear lazy web”, pare che mi tocchi clonare tutta la storia di un singolo repository per fare un singolo commit+push.

No cioè… questo è quello che è lo stato di evolution-data-server: http://git.gnome.org/cgit/evolution-data-server/refs/ ? Io dovrei scaricare tutta quella roba? Per fare un commit io dovrei scaricare 10 anni di storia di un repository quando mi servono master e gnome-2-26?

Se uso –depth 1 pare non ci sia molto guadagno… ma posso lo stesso fare il commit+push usando l’opzione –depth 1 visto che non è una copia vera e propria?

Se domani volessi mettermi a compilare con jhbuild devo comprare un NAS da 8 TiB?

14 commenti
  1. aldolat ha detto:

    pare ora che i permessi siano errati sul file, ma in teoria dovrebbe funzionare lo stesso, più tardi controllo

    Ti confermo che il nuovo .mo funziona. Tienici aggiornati sui permessi.

  2. Milo ha detto:

    Mah… io ho provato prima a scaricare il file dal wiki e i permessi sono corretti.

  3. gaspa ha detto:

    Se impari come si fa a fare quella cosa con git, ti prego, dimmelo. Io non l’ho ancora capito.

  4. Paolo ha detto:


    Se uso –depth 1 pare non ci sia molto guadagno… ma posso lo stesso fare il commit+push usando l’opzione –depth 1 visto che non è una copia vera e propria?

    IMO si. Ed il guadagno dovrebbe essere grande.

  5. “Given that the status says ‘Converting /mnt/git-data/svn/perl-Gtk2-GLExt’, I’d like to say that totem-pl-parser also didn’t seem to pass the import stage.”

    Quote: Bastien Nocera

    Hhhhhmmmmmm

  6. Milo ha detto:

    @Paolo:
    boh… prima mi sono messo a leggere l’aiuto di git clone, dice:

    A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

    Su GNOME dicono che in teoria si può fare, ma lo sconsigliano… e sinceramente non mi va di fare da cavia!🙂

  7. Milo ha detto:

    Chissà che non glieli importino tutti a Bastien i moduli!😀

  8. Paolo ha detto:

    Ok, ma veramente il “risparmio” con depth 1 sono ridotti?

    Devi per forza fare push? Non puoi inviare i contributi via mail con git format-patch e git send?

    Non conosco il workflow di gnome quindi magari dico una grande sciocchezza😉

  9. Milo ha detto:

    Ho fatto proprio una prova. Allora:
    git clone -> 84.7 MiB
    git clone –depth 1 -> 77.8 MiB

    Non è male, ma non è neanche tutto questo guadagno. Tra l’altro c’è da capire cosa indica git alla fine del “clone” perché diceva rispettivamente: 29.07 e 23.4 MiB…

    Per la questione di fare push… beh… ho dovuto smuovere mari e monti per avere un account SVN che dopo 6 mesi non mi avevano ancora dato, vuoi che mandi le patch via mail?🙂

    Volendo puoi inviare le patch (credo anche in quel modo, ma visto che il passaggio a git è di questi giorni, non lo so), ma a quel punto non mi serve nemmeno il repository, mi prelevo il file che devo modificare via web…

    È interessante notare come in soli 34 MiB di file .git ci sia tutta la history…

  10. Paolo ha detto:

    Quando dici 84 e 77 MiB a cosa ti riferisci?
    Alla dimensione della sola dir .git o sommi anche la working dir?

    Git clone dovrebbe dirti la sola dimensione del repository git, non contando quindi il checkout.

    Se non vuoi fare il checkout automatico dopo il clone puoi usare:
    git clone -n URL

    Detto questo mi aspettavo in guadagno maggiore nell’uso di depth1

  11. Milo ha detto:

    @Paolo:
    la dimensione è la dimensione della directory dopo il clone presa utilizzando Baobab.

    Quei valori che mi ritorna git dopo il clone (29.7 e 23.4) potrebbero essere la dimensione della dir .git, ma sempre Baobab riporta appunta 34 MiB (per quella normale, per l’altra non ricordo, l’ho anche eliminata).

  12. Paolo ha detto:

    Ho fatto un clone -n

    risultato:
    Paolo@CASA ~
    $ du -h evolution-data-server/
    52K evolution-data-server/.git/hooks
    1.0K evolution-data-server/.git/info
    1.0K evolution-data-server/.git/logs/refs/heads
    1.0K evolution-data-server/.git/logs/refs/remotes/origin
    1.0K evolution-data-server/.git/logs/refs/remotes
    2.0K evolution-data-server/.git/logs/refs
    3.0K evolution-data-server/.git/logs
    0 evolution-data-server/.git/objects/info
    32M evolution-data-server/.git/objects/pack
    32M evolution-data-server/.git/objects
    1.0K evolution-data-server/.git/refs/heads
    1.0K evolution-data-server/.git/refs/remotes/origin
    1.0K evolution-data-server/.git/refs/remotes
    0 evolution-data-server/.git/refs/tags
    2.0K evolution-data-server/.git/refs
    32M evolution-data-server/.git
    32M evolution-data-server/

  13. Milo ha detto:

    @Paolo:
    Ma in quel modo ho una directory “virtualmente” vuota (non ha file all’interno se non solo .git). Se voglio modificare un file devo fare il checkout e si ritorna sempre agli 85 mega di prima…

    Il non fare il checkout di HEAD non vuol dire che non scarica altri file, ma vuol dire che non “popola” la directory. “git clone” scarica anche lui la history, ma in automatico fa anche il checkout (e non scarica altri dati quando lo faccio).

    Alla fine dei conti, “git clone” e “git clone -n” non sono molti differenti, scaricano sempre 34 mega di dati, solo che con “git clone -n” ha un’operazione in più a mano da fare dopo per popolare effettivamente il repository locale.

  14. Paolo ha detto:

    Corretto.

    La mia voleva solo essere una puntualizzazione in merito a:

    git clone -> 84.7 MiB
    git clone –depth 1 -> 77.8 MiB

    Il giusto confronto e’ da fare sulle solo dir .git in quanto la dimensione del checkout e’ ovviamente uguale nei due casi.

    Insomma, git e’ molto bravo a comprimere la history di un progetto, tipicamente una dir .git di un progetto con anni di storia e’ cmq di dimensione inferiore rispetto ad un suo checkout.


    Alla fine dei conti, “git clone” e “git clone -n” non sono molti differenti, scaricano sempre 34 mega di dati, solo che con “git clone -n” ha un’operazione in più a mano da fare dopo per popolare effettivamente il repository locale.

    Si parlando di quantita’ di dati scaricati e si se se interessato alla branch master, se invece sei interessato ad una branch differente git clone -n ti fa risparmiare un po’ di tempo in quanto ti eviti un primo checkout inutile.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: