Dovrei analizzare git status o l'uso gitsharp?

Question

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

Devo analizzare il testo in uscita git status per determinare lo stato della cartella o devo usare qualche strumento involucro di comunicare correttamente con git?

stavo pensando gitsharp dal momento che è facile chiamare dotNet oggetti da MaxScript, ma non ho usato programmi dotNet esterni.

Answer 1

Il mio tentativo di risolvere questo ha comportato l'analisi git status. Sembra pulito e più facile da implementare. D'altra i'am mano alla ricerca forword per creare una speciale file XML artigianale per ottenere le informazioni necessarie in modo più "pulito".

Answer 2

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 di porcellana è simile al formato breve, ma è garantito di non cambiare in modo retro-compatibili tra le versioni git o in base alla configurazione dell'utente.          Questo lo rende ideale per l'analisi dagli script. La descrizione del formato breve sopra anche descrive il formato in porcellana, con alcune eccezioni:

     

  
1. Configurazione color.status dell'utente non è rispettata; il colore sarà sempre off.
  
2. Configurazione status.relativePaths dell'utente non è rispettata; percorsi visualizzati saranno sempre relativo alla radice repository.
  

     

C'è anche un formato -z alternativa consigliata per l'analisi della macchina. In questo formato, il campo di stato è lo stesso, ma cambia alcune altre cose. In primo luogo, il -> è omesso          dalle voci rinominare e l'ordine dei campi viene invertito (per esempio da -> per diventa a partire da). In secondo luogo, un NUL (ASCII 0) segue ogni nome di file, sostituendo spazio come separatore di campo          e la fine riga (ma uno spazio ancora separa il campo di stato dal primo file). In terzo luogo, i nomi di file contenenti caratteri speciali non sono particolarmente          formattato; non citando o viene eseguita backslash-fuga.

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

git status -z

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

Answer 3

git contiene generalmente "porcellana", i comandi di alto livello progettati per l'interazione uso quotidiano, e "idraulico", che sono comandi di basso livello che hanno, semplici interfacce stabili per costruire più porcellanato. È possibile trovare un elenco nel git . Per utilizzare l'esempio di Sergo, git ls-files è l'impianto idraulico per git status. Avvolgendo l'impianto idraulico è più facile e più sicuro che la porcellana, anche se può richiedere qualche sconcertante per capire quale set di mappe idraulici a ciò porcellana.

Answer 4

ho scoperto git ls-files e sono totalmente soddisfatto con il suo formato di output. git status era troppo umano-orientato per l'analisi.

Io preferirei Mercurial per git con il suo comando status chiaro, ma con grandi file binari sembra che git funziona meglio per me.

Answer 5

Non so nulla di MAXScript ma se a capire come chiamare assembly .NET quindi è possibile utilizzare gitsharp e penso che sarebbe l'opzione migliore e più semplice!

avere uno sguardo ai test di unità delle API gitsharp. mostrano come ottenere le operazioni di stato e altre di livello elevato, come commettere, rami commutazione, controllando, visualizzazione cambiamenti di commit e così via.

- henon

Answer 6

Un sacco di max sta già utilizzando assembly .NET. Questo dovrebbe essere la cosa più facile per sviluppare su. Oltre l'analisi del testo .... è così fragile. Avevo appena dimenticare l'analisi del testo.