Devo analizzare lo stato di git o usare gitsharp?

Question

Mi piacerebbe integrare git nella pipeline di produzione per mettere in scena i file 3dsmax. Mentre è giusto lavorare con git attraverso TortoiseGit, mi piacerebbe comunicare con esso dal Maxscript per aggiungere comandi di menu personalizzati a 3dsmax.

Devo analizzare il testo di output git status per determinare lo stato della cartella o dovrei usare uno strumento di wrapping per comunicare correttamente con git?

Stavo pensando a gitsharp poiché è facile chiamare gli oggetti dotNet da Maxscript, ma non ho usato programmi dotNet esterni.

Answer 1

Il mio tentativo di risolvere questo ha comportato l'analisi dello stato di git. Sembra più pulito e facile da implementare. D'altra parte sto cercando forword per creare uno speciale file XML creato per ottenere le informazioni necessarie in un modo più "pulito".

Answer 2

Ho scoperto git ls-files e sono assolutamente soddisfatto del suo formato di output. git status era troppo umano per l'analisi.

Preferirei Mercurial a git con il suo comando di stato chiaro, ma con file binari di grandi dimensioni sembra che git funzioni meglio per me.

Answer 3

git contiene generalmente "porcellana", comandi di alto livello progettati per l'interazione quotidiana dell'utente e "plumbing" che sono comandi di basso livello che hanno interfacce semplici e stabili per costruire più porcellane. È possibile trovare un elenco nello git man page. Per utilizzare l'esempio di sergo, git ls-files è l'impianto idraulico per git status. Avvolgere l'impianto idraulico è più facile e più sicuro della porcellana, anche se potrebbe essere necessario qualche sconcertante per capire quale serie di mappe idrauliche a quale porcellana.

Answer 4

Non so nulla di maxscript ma se si capisce come chiamare .net assembly allora è possibile utilizzare gitsharp e penso che sarebbe l'opzione migliore e più semplice!

dai un'occhiata ai test delle unità dell'API gitsharp. mostrano come ottenere lo Status e altre operazioni di alto livello come ad esempio commit, cambio rami, check out, visualizzazione di modifiche di un commit e così via.

- henon

Answer 5

Dal git versione 1.7.0, v'è stata una scelta --porcelain per git status. L'uscita di:

git status --porcelain 

... è stato progettato per l'utilizzo da parte degli script - una rappresentazione compatta dell'uscita cui formato rimarrà coerente tra le versioni. Mentre la pagina man dice:

porcellana Formato

Il formato in porcellana è simile al formato breve, ma è garantito di non cambiare in modo retro-compatibili tra le versioni git o in base a configurazione utente . Ciò lo rende ideale per l'analisi tramite script. La descrizione del formato breve sopra descrive anche il formato di porcellana, con alcune eccezioni:

1. La configurazione color.status dell'utente non è rispettata; il colore sarà sempre spento.
2. Lo stato dell'utente.la configurazione relativaPath non è rispettata; i percorsi mostrati saranno sempre relativi alla radice del repository.

C'è anche un formato -z alternativo consigliato per l'analisi della macchina. In questo formato, il campo dello stato è lo stesso, ma alcune altre cose cambiano. Innanzitutto, il -> viene omesso dalle voci di rinomina e l'ordine dei campi viene annullato (ad esempio da -> a diventa a da). In secondo luogo, un NUL (ASCII 0) segue ogni nome file, sostituendo lo spazio come separatore di campo e la fine riga di terminazione (ma uno spazio separa ancora il campo dello stato dal primo nome file). In terzo luogo, i nomi di file contenenti caratteri speciali non sono formattati in modo speciale ; non viene eseguita alcuna quotatura o escape backslash.

Così, come che dice, si potrebbe anche voler considerare l'utilizzo di:

git status -z 

... per un formato di uscita ancora più robusta.

Answer 6

Un sacco di max sta già utilizzando gli assembly .NET. Questa dovrebbe essere la cosa più facile da sviluppare. Oltre ad analizzare il testo .... è così fragile. Mi dimentico di analizzare il testo.