2009-12-30 20 views
5

Me gustaría integrar git en la canalización de producción para crear archivos stage 3dsmax. Si bien está bien trabajar con git a través de TortoiseGit, me gustaría comunicarme con él desde Maxscript para agregar comandos de menú personalizados a 3dsmax.¿Debo analizar el estado de git o usar gitsharp?

¿Debo analizar el texto de salida git status para determinar el estado de la carpeta o debo usar alguna herramienta de embalaje para comunicarme correctamente con git?

Estaba pensando en gitsharp ya que es fácil llamar a objetos dotNet desde Maxscript, pero no utilicé programas dotNet externos.

Respuesta

2

Mi propio intento de resolver esto dio como resultado el análisis del estado de git. Parece más limpio y más fácil de implementar. Por otro lado, busco la palabra para crear un archivo XML especialmente diseñado para obtener la información necesaria de una manera más "limpia".

+0

Gracias, bastianeu! ¿Y de dónde planifica obtener ese archivo XML? ¿Se puede forzar al propio git a crear dicho archivo? Lo siento, soy un principiante en la administración de git. – sergo

+0

Al analizar la salida de git por mí mismo, puedo crear un archivo XML. Que se puede usar para varias cosas ... – bastianneu

+1

El análisis de comandos de "porcelana" es una muy mala idea. La salida está pensada para humanos, y como tal, el formato puede cambiar entre versiones de git (por ejemplo, si agregan más información útil o la reorganizan para que sea más fácil de leer). La respuesta correcta es usar los comandos de "plomería", como Schwern enumera a continuación. – davr

2

Descubrí git ls-files y estoy totalmente satisfecho con su formato de salida. git status era demasiado orientado a los humanos para analizar.

Preferiría Mercurial a git con su comando de estado claro, pero con archivos binarios grandes parece que git funciona mejor para mí.

7

git generalmente contiene "porcelana", comandos de alto nivel diseñados para la interacción diaria del usuario, y "plomería", que son comandos de bajo nivel que tienen interfaces simples y estables para construir más porcelana. Puede encontrar una lista en el git man page. Para usar el ejemplo de sergo, git ls-files es la tubería para git status. Envolver la tubería es más fácil y más seguro que la porcelana, aunque puede requerir un poco de desconcierto averiguar qué conjunto de mapas de fontanería para qué porcelana.

0

No sé nada sobre maxscript pero si descubres cómo llamar a los ensamblados .net entonces puedes usar gitsharp y creo que sería la mejor y más fácil opción.

eche un vistazo a las pruebas unitarias de la API de gitsharp. Muestran cómo obtener el estado y otras operaciones de alto nivel, como la confirmación, el cambio de sucursales, el control de salida, la visualización de cambios de una confirmación, etc.

- Henon

+0

Gracias, henon. Finalmente, encontré el método para ejecutar gitsharp desde maxscript (mediante el método Assembly.LoadFrom). Funciona bien, pero no soy fuerte en C#, por lo que me resulta un poco difícil buscar entre las fuentes. Incurrirá en personas en los grupos de google de gitsharp. – sergo

+0

no hay problema, eres bienvenido! También hay una nueva documentación de API que necesitamos mejorar más, pero aún así es mejor que nada. ver http://henon.github.com/GitSharp/ – henon

8

Desde la versión 1.7.0 de Git, no ha sido una opción para --porcelaingit status. La salida:

git status --porcelain 

... está diseñado para su uso por los scripts - una representación compacta de la salida cuyo formato se mantendrá consistente a través de versiones. Como la página del manual dice:

Formato Porcelana

El formato de porcelana es similar al formato corto, pero se garantiza que no cambie de manera hacia atrás incompatibles entre versiones Git o en base a la configuración del usuario . Esto lo hace ideal para el análisis mediante scripts. La descripción del formato corto anterior también describe el formato de porcelana, con algunas excepciones:

  1. No se respeta la configuración del color.status del usuario; el color siempre estará apagado.
  2. El estado del usuario.la configuración relativa de Path no se respeta; las rutas mostradas siempre serán relativas a la raíz del repositorio.

También hay un formato -z alternativo recomendado para el análisis de máquina. En ese formato, el campo de estado es el mismo, pero algunas otras cosas cambian. Primero, el -> se omite de las entradas de cambio de nombre y el orden de los campos se invierte (por ejemplo, desde -> se convierte a desde). Segundo, un NUL (ASCII 0) sigue a cada nombre de archivo, reemplazando el espacio como un separador de campo y la nueva línea de terminación (pero un espacio aún separa el campo de estado del primer nombre de archivo). En tercer lugar, los nombres de archivos que contienen caracteres especiales no tienen formato especial ; no se realiza el salto de comillas o saltos de barras invertidas.

lo tanto, como que dice, es posible que también desee considerar el uso:

git status -z 

... para un formato de salida aún más robusto.

0

Muchos de los max ya están utilizando ensamblados .NET. Eso debería ser lo más fácil de desarrollar. Además de analizar texto ... es tan frágil. Me olvidaría de analizar el texto.