我应该解析git状态还是使用gitsharp？

我想将git集成到生产管道中，以准备3dsmax文件。虽然通过Ortoisegit使用git是可以的，但我希望通过Maxscript与git通信，向3dsmax添加自定义菜单命令

我应该解析

git状态

输出文本来确定文件夹状态，还是应该使用一些包装工具来正确地与git通信

---

我在考虑gitsharp，因为从Maxscript调用dotNet对象很容易，但我没有使用外部dotNet程序。

我自己解决这个问题的尝试导致了对git状态的解析。看起来更干净，更容易实现。另一方面，我希望Word创建一个特制的XML文件，以更“干净”的方式获取所需信息。

我发现了

git ls文件

，我对其输出格式完全满意<代码>git状态对于解析来说太人性化了

---

我更喜欢

Mercurial

而不是

git

，因为它有清晰的状态命令，但是对于大的二进制文件来说，

git

似乎对我更合适。

git通常包含“瓷器”，为日常用户交互设计的高级命令，以及“管道”，它们是具有简单，稳定的接口，以建立更多的瓷器。您可以在中找到一个列表。以sergo为例，

git ls文件

是

git状态

的管道。包装管道比瓷器更简单、更安全，但要弄清楚哪套管道映射到哪种瓷器可能需要一些困惑。

我对maxscript一无所知，但如果你知道如何调用.net程序集，那么你可以使用gitsharp，我想这将是最好、最简单的选择

看看gitsharp API的单元测试。它们显示了如何获取状态和其他高级操作，如提交、切换分支、签出、查看提交的更改等

---

--henon

自从git版本1.7.0以来，已经有了一个

--ceral

选项，用于

git状态

。输出：

git status --porcelain

。。。是为脚本使用而设计的-输出的紧凑表示形式，其格式在各个版本之间保持一致。正如手册页所说：

陶瓷格式

瓷格式类似于短格式，但保证不会在git版本之间或基于用户配置以向后不兼容的方式进行更改。 这使得它非常适合通过脚本进行解析。上述简短格式的描述也描述了陶瓷格式，但有几个例外：

不尊重用户的color.status配置；颜色将永远是关闭的

不尊重用户的status.relativePath配置；显示的路径将始终相对于存储库根目录

对于机器解析，还建议使用另一种-z格式。在该格式中，状态字段是相同的，但其他一些内容会发生变化。首先，省略->命令 从重命名条目开始，字段顺序颠倒（例如从->到变为从）。其次，每个文件名后面都有一个NUL（ASCII 0），将空格替换为字段分隔符 和终止换行符（但状态字段与第一个文件名之间仍有一个空格）。第三，包含特殊字符的文件名不是特殊的 格式化；不执行引用或反斜杠转义

这样，你也可以考虑使用：

git status -z

---

。。。为了获得更健壮的输出格式。

很多max已经在使用.NET程序集。这应该是最容易发展的事情。除了解析文本。。。。它是如此脆弱。我忘了分析文本。

谢谢你，巴斯蒂亚诺！您计划从哪里获取XML文件？git本身是否可以被迫创建这样的文件？对不起，我是git管理的新手。当我自己解析git输出时，我能够创建一个XML文件。这可以用于各种事情……解析“瓷器”命令是一个非常糟糕的主意。输出是针对人类的，因此，格式可能会在git版本之间发生变化（例如，如果他们添加了更多有用的信息，或者重新排列以便于人们阅读）。正确的答案是使用“管道”命令，如下面Schwern所列。谢谢你，henon。我终于找到了从maxscript运行gitsharp的方法（通过Assembly.LoadFrom方法）。它工作得很好，但我的C#能力不强，所以对我来说搜索来源有点困难。会在gitsharp的google-groups上骚扰人们。没问题，欢迎你！还有一个新的API文档，我们需要进一步改进，但它总比什么都没有好。看见