Should I parse git status or use gitsharp?

Question

I'd like to integrate git into production pipeline to stage 3dsmax files. While it is alright to work with git through TortoiseGit, I'd like to communicate with it from the Maxscript to add custom menu commands to 3dsmax.

Should I parse git status output text to determine folder status or should I use some wrapping tool to correctly communicate with git?

I was thinking about gitsharp since it is easy to call dotNet objects from Maxscript, but I didn't use external dotNet programs.

Faa

Answer 1

My own attempt to solve this resulted in parsing git status. Seems cleaner and easier to implement. On the other hand i'am looking forword to create an special crafted XML File to get the needed Information in a more "clean" Way.

Hydrangea

Thank you, bastianeu! And where you're planning to get that XML file from? Is git itself could be forced to make such file? Sorry, I'm novice in git management. – Faa

As i parsed git output by myself i am able to create an XML File. That can be used for various things... – Hydrangea

Parsing "porcelain" commands is a very bad idea. The output is intended for humans, and as such, the format may change between git versions (eg if they add more useful info, or re-arrange it to be easier for people to read). The correct answer is to use the "plumbing" commands, as Schwern lists below. – Infiltrate

Answer 2

Since git version 1.7.0, there has been a --porcelain option for git status. The output of:

git status --porcelain

... is designed for use by scripts - a compact representation of the output whose format will remain consistent across versions. As the man page says:

Porcelain Format

The porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between git versions or based on user configuration. This makes it ideal for parsing by scripts. The description of the short format above also describes the porcelain format, with a few exceptions:

1. The user’s color.status configuration is not respected; color will always be off.
2. The user’s status.relativePaths configuration is not respected; paths shown will always be relative to the repository root.

There is also an alternate -z format recommended for machine parsing. In that format, the status field is the same, but some other things change. First, the -> is omitted from rename entries and the field order is reversed (e.g from -> to becomes to from). Second, a NUL (ASCII 0) follows each filename, replacing space as a field separator and the terminating newline (but a space still separates the status field from the first filename). Third, filenames containing special characters are not specially formatted; no quoting or backslash-escaping is performed.

So, as that says, you may also want to consider using:

git status -z

... for an even more robust output format.

Gaberlunzie

Answer 3

git generally contains "porcelain", high level commands designed for everyday user interaction, and "plumbing" which are low level commands which have simple, stable interfaces to build more porcelain. You can find a list in the git man page. To use sergo's example, git ls-files is the plumbing for git status. Wrapping the plumbing is easier and safer than the porcelain, though it may require some puzzling to figure out what set of plumbing maps to what porcelain.

Wapentake

Answer 4

I've discovered git ls-files and I'm totally satisfied with its output format. git status was too human-oriented for parsing.

I would prefer Mercurial to git with its clear status command, but with large binary files it seems that git works better for me.

Faa

Answer 5

I don't know nothing about maxscript but if you figure out how to call .net assemblies then you can use gitsharp and I think it would be the best and easiest option!

have a look at the unit tests of the gitsharp API. they show how to get the Status and other high level operations such as committing, switching branches, checking out, viewing changes of a commit and so on.

-- henon

Giliane

Thank you, henon. I've finally find the method to run gitsharp from maxscript (by Assembly.LoadFrom method). It works fine, but I'm not strong in C#, so it's little hard for me to search through the sources. Will bug people at gitsharp's google-groups. – Faa

no problem, you are welcome! There is also a new API documentation which we need to improve more, but still it's better than nothing. see henon.github.com/GitSharp – Giliane

Answer 6

A lot of max is already using .NET assemblies. That should be the easiest thing to develop on. Besides parsing text.... is so fragile. I'd just forget about parsing text.

Allophone