C'è un modo per sfogliare e visualizzare i file in un repository git senza clonarlo prima? Posso fare quelle svn utilizzando i comandi:Sfoglia e visualizza i file in un repository git senza clonazione
svn ls /path/to/repo svn cat /path/to/repo/file-in-repo
posso presumibilmente utilizzare git show, ma fare:
git show /path/to/repo git show HEAD:/path/to/repo
risultato
fatal: Not a git repository
Il comando che si desidera è git ls-remote che permette per ottenere alcune informazioni sui repository remoti, ma non puoi mostrare la cronologia o elencare le directory o qualsiasi cosa di quel livello: essenzialmente ti consente di vedere solo gli oggetti remoti a un livello molto alto vel (puoi vedere gli attuali HEAD e tag ad esempio).
L'unico vero modo per fare quello che vuoi (se ho capito bene) sarebbe quella di usare ssh per eseguire un comando remoto e restituire i risultati, ad esempio:
ssh [email protected] "cd repo && git log -n 10"
Ciò che si vuole sarebbe bello funzionalità se potessero aggiungerlo, ma da quello che ho letto non è molto semplice dato che ottenere la cronologia, ecc., richiede un sacco di informazioni per essere git locali, ea quel punto si potrebbe anche aver fatto un git fetch.
Git è distribuita sistema di controllo versione, mentre Subversion è centralizzato sistema di controllo versione (client-server). Funzionano diversamente; abituarsi a questo. Si prega di leggere la mia risposta spiegando le conseguenze di tale differenza alla domanda git equivalent of svn status -u su StackOverflow.
ripetermi un po ': nel sistema di controllo di versione centralizzato (come CVS o Subversion) quasi tutti i comandi vengono elaborati sul server di, e coinvolgere rete. Pochissimi comandi sono eseguiti localmente. Si noti che per avere buone prestazioni di "svn status" e "svn diff" Subversion memorizza la copia "pristine" della versione check-out sul client, per non dover coinvolgere il trasferimento di rete per quelle operazioni comuni (questo significa che Subversion checkout = 2 x dimensione della directory di lavoro almeno).
Nel sistema di controllo versione distribuita (come Git, Mercurial o Bazaar), in cui si dispone di copia locale (clone) di un intero repository, quasi tutti i comandi vengono eseguiti sul client. Pochissimi comandi richiedono una connessione di rete ad altro repository (al server).
Il numero di comandi che è possibile eseguire sul server è limitato.
Corretti come sei, se stai navigando su un repository remoto senza prima clonarlo, allora ovviamente hai deciso che è ok rinunciare alle funzionalità offline di git. Detto questo, non vedo alcun motivo per fingere che questa non sarebbe una caratteristica utile per alcune cose, ad esempio un client locale che consente di navigare localmente sul contenuto del file di un repository remoto. – LadyCailin
D'accordo, la posizione che assume Jakub è altamente restrittiva. Vale la pena perdere la reputazione più di una volta per farlo notare. – ctpenrose
Non mi piace il tono "abituati a quello", ma quando ho letto fino alla fine ho trovato una soluzione al mio problema corrente - mi piacerebbe vedere cosa c'è nel repository 110 ho un git, ma non ho accesso a ssh o shell, e quale probabilmente sono abbastanza grandi, circa 12 GB o giù di lì. Quindi il clone con una profondità minuscola aiuta almeno a vedere solo la storia interessante recente. e rendere il repository git il più piccolo possibile. – Henning
Dai uno sguardo a http://git-scm.com/book/en/Git-Internals-Transfer-Protocols per informazioni su come eseguire questa operazione su alcuni protocolli di trasporto. Nota che questo non funzionerà con git standard su SSH.
Per git su SSH, un git server-side aggiornato dovrebbe consentire di archiviare git direttamente dal remoto, che a questo punto si potrebbe ad es. pipe to "tar t" per ottenere un elenco di tutti i file in un dato commit.
Probabilmente questo è considerato sporco da alcuni, ma una soluzione molto pratica in caso di repository github è solo per creare uno script, ad es. "Git-ls":
#!/bin/sh
remote_url=${1:? "$0 requires URL as argument"}
curl -s $remote_url | grep js-directory-link | sed "s/.* title=\"\(.*\)\".*/\1/"
renderlo eseguibile e raggiungibile, naturalmente: chmod a+x git-ls; sudo cp git-ls /usr/local/bin. Ora, basta eseguire come si desidera:
git-ls https://github.com/mrquincle/aim-bzr
git-ls https://github.com/mrquincle/aim-bzr/tree/master/aim_modules
sanno anche che esiste un'utility git instaweb per i file locali. Per avere la capacità di mostrare i file e avere un server simile, a mio parere non distruggere nessuna delle caratteristiche intrinseche decentralizzate di git.
Non sto ottenendo alcun risultato con questo. il ricciolo non sembra restituire nulla. –
Ora raccomanderei sicuramente il metodo API di Anarug. Questo metodo funziona comunque: 'curl -s https://github.com/Itseez/opencv | grep js-directory-link | sed 's |. * title = "\ (. * \)". * | \ 1 |' ' –
Non l'esatto, ma un modo per aggirare.
Usa GitHub API per sviluppatori
Apertura questo ti porterà i commit recenti.
https://api.github.com/repos/learningequality/ka-lite/commits
È possibile ottenere la specifica commit dettagli allegando l'hash impegnarsi alla fine del precedente URL.
Tutti i file (È necessario sha per l'albero principale)
Spero che questo può aiutare.
Non confondere Git con GitHub - Credo che le domande originali riguardassero Git stesso. Le installazioni/hosting Git (GitHub/BitBucket/Stash) possono avere varie possibilità per i repository dei browser. –
Buona idea @Anurag Kanungo Pensare fuori dagli schemi – eonist
GitHub è SVN compatibile in modo da poter utilizzare ls svn
svn ls https://github.com/user/repository.git/branches/master/
BitBucket supporta archivio git in modo da poter scaricare archivio tar e l'elenco dei file archiviati. Non è molto efficiente, ma funziona:
git archive [email protected]:repository HEAD directory | tar -t
Non confondere Git con GitHub :) –
se si conosce il ramo remoto che si desidera controllare, è possibile scoprire le ultime tramite:
git ls-tree -r <remote_branch> --name-only
Una cosa si può fare con 'clone' git , comunque, è quello di recuperare solo una singola revisione passando '--depth 1'. Questo evita di recuperare grandi quantità di cronologia e sarebbe sufficiente per rispondere a domande come "quali file sono presenti nella revisione' abcdef1234567890'? " – ctrueden